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FOREWORD 

The Space Station Systems Technology Study (Contract NAS8-34893) was initiated in 
June 1983 and to be completed in April 1984. The study was conducted for the National 
Aeronautics and Space Administration, Marshall Space Flight Center, by the Boeing 
Aerospace Company with Spectra Research Systems as a subcontractor. The study final 
report is documented in three volumes. 
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Mr. Robert F. Nixon was the Contracting Officer's Representative and Study Technical 
Manager for the Marshall Space Flight Center. Dr. Richard L. Olson was the Boeing 
study manager with Mr. Paul Meyer as the technical leader, and Mr. Rodney Bradford 
managed the Spectra Research Systems effort. A lifting of the key study team members 
follows. 
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1.0 INTRODUCTION 


This is volume II of the final report on the Space Station Systems Technology Study 
conducted for the Marshall Space Flight Center (MSFC) by the Boeing Aerospace 
Company (BAC) and Spectra Research Systems (SRS). The overall study objective was to 
identify, quantify, and justify the advancement of high-leverage technologies for 
application primarily to the early space station. The objective was fulfilled through a 
systematic approach tailored to each of the technology areas studied. This volume 
presents the results of the technical effort. Volume III discusses the research plans 
developed for each of the selected high-leverage technologies. 

The current Space Station Systems Technology Study was an outgrowth of the Advanced 
Platform Systems Technology Study (APSTS) that was completed in April 1983 for MSFC 
by the Boeing/SRS team. The first APSTS proceeded from the identification of 106 
technology topics to the selection of five for detailed trade studies. During the 
advanced platform study, the technical issues and options were evaluated through 
detailed trade processes. Individual consideration was given to costs and benefits for the 
technologies identified for advancement, and advancement plans were developed. An 
approach similar to this was used in the current study, with emphasis on system defini- 
tion in four specific technology areas. 

The four study areas addressed in the Space Station Systems Technology Study are: (1) 
Attitude Control, (2) Data Management, (3) Long-Life Thermal Management, and (4) 
Automated Housekeeping Integration. These four areas are extensions of the APSTS and 
were conducted to facilitate a more in-depth analysis of technology issues. While each 
of the study areas had high-leverage technology identification as a goal, different study 
approaches were required. The attitude control study utilized a specific representative 
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configuration and determined by simulation the applicability of a low bandwidth control 
system for space station use. The data management study concentrated on the 
characterization of the architecture into structural blocks and systems to facilitate 
simulation planning. The thermal study focused on characterizing a two-phase heat 
transport systems within the long life requirement constraints. Finally, the automated 
housekeeping task was structured to characterize the functions of an integrating 
controller for an overall management system. Each of these approaches produced useful 
advancements in the understanding of technology issues and development needs and are 
discussed in detail in the following sections. The topics of discussion include the planned 
approach, technical discussion, summary of results, conclusions, and recommendations. 

The overall study was divided into four tasks. During task 1 the design concepts required 
in each of the four study areas were refined. The concepts were used to describe 
specific technology options upon which comparative studies were conducted. Candidate 
high-leverage advancement technologies were then selected from the options. The cost, 
benefits, schedules, and life cycle costs for each of the options were evaluated in task 2. 
Selection of the technology advancement items was made during this latter task. 
Technology advancement plans were prepared for each of the selected items in task 3. 

All study documentation was prepared in task 4. The overall study schedule is shown in 
figure 1.0-1. 

Seven potential technology advancement items were identified during this study. These 
items were analyzed and evaluated in Task 2, considering technical as well as cost 
benefits and schedule criteria. Study plans were prepared for each of the selected high- 
leverage items. These selected items are: 
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Figure 1.0- 1 Program Schedule 
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1. Data Management System Simulation Package. 

2. Data Management Network Interface Unit. 

3. Data Management Network Operating System. 

4. Two Phase Thermal - Long-Life Pumps. 

v 

5. Two Phase Thermal - Heat Exchanger. 

6. Two Phase Thermal - Two-Phase Water System. 

7. Integrating Controller for Space Station Autonomy using Expert Systems. 

This volume presents the technical work performed to select these high-leverage items. 
The total final report is made up of this volume, Volume I: Executive Summary, and 
Volume III: Technology Advancement Program Plan. 
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2.0 ATTITUDE CONTROL 


2.1 INTRODUCTION 

2.1.1 Objectives 

The objective of the study was to initiate the development of technologies required for 
the solution of the control-structure interaction problem in space station design. The 
approach was to determine through analysis and simulation the degree to which non- 
interacting low -band controller technology is applicable to attitude regulation of a space 
station with large flexible solar arrays. Primary emphasis was given to identifying the 
limitations of low -band controller technology for flexible space station applications. 
Passive and active control technologies were to be reviewed as potential improvements 
to the damping provided by a low -band controller in the event that attitude stability and 
performance were unacceptable. 

The term low -band control is somewhat misleading in the present context. The applica- 
tion of low band design usually implies a band limiting of the control signal. In the pres- 
ence of significant structural interaction with the core station band limiting the control 
signal eliminates a significant portion of the attitude error information contained in the 
output. In this study all the available attitude information, including flexible effects 
measured by a sensor package mounted on the core station, is passed to a linear actuator 
that attempts to control the attitude about the center of mass. The sensors are assumed 
to measure attitude and its rate about three body axes. The measurements are ideal to 
the degree that the sensors are assumed to be error free with infinite bandwidth. The 
linear actuators were modeled as ideal control moment gyros (CMG). The low -band 
controller will therefore attempt to regulate attitude in the presence of induced distur- 
bance torques due to flexibility without actively controlling the motion of the flexible 
elements. The control system is said to be reactive rather than active in the sense that 
the core mounted controller reacts to external disturbance rather than actively 
influencing the disturbance source resulting from appendage flexing. It will be demon- 
strated that a core mounted linear ideal controller is stable in the presence of flexibility 
and will provide significant damping of most of the major structural modes. However, 
some of the modes cannot be controlled with a core mounted controller. The important 
question is the amplitude to which the controlled modes are excited and the implications 
of sustained vibration of the associated structural members. 
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The objectives of the study tasks are described as follows. 

1. Evaluate the stability and performance of reactive CMG control laws for impulsive 
internal disturbances during productive work periods as the space station evolves. 
The worst case impulsive disturbances are assumed to originate from crew activity 
and mechanical equipment. The open loop response of the structure to docking loads 
is also evaluated. 

2. Suggest methods of improving the pointing performance by passive damping tech- 
niques. A secondary task objective is to determine alternate methods to obtain 
active damping of structural modes by prudent placement of actuators and motion 
sensors. 

t 

2.1.2 Issues 

The principle issues that impact the development of an automatic flight control system 
for space station are related to the interaction between the control system and struc- 
ture. 

Tight pointing accuracy requirements produce associated requirements for increased 
control system bandwidth. As controller bandwidth increases, many structural modes 
will be included within the controller passband. Active stabilization of these modes 
without sacrificing pointing accuracy is a major issue. Adapting to variations in mode 
shapes and frequencies caused by space station configuration changes is also a major 
issue when active damping of structural modes is required. In an effort to reduce control 
system complexity, the development of passive techniques for structure mode damping is 
a significant issue. Structural stiffness and damping characteristics are, therefore, 
crucial to control system design, and early attention must be given to configuration op- 
tions that increase modal frequency and damping. 

Avoiding the interaction of control system and structure is an attractive alternative. 

The reactive controller achieves this objective with an attendant reduction in control 
system complexity. The important issue is the controllability of the structure and the 
resultant lightly damped response to be expected from a reactive controller. 
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2.1.3 Advanced Platform Systems Technology Study Background 

This study is the continuation of the Advanced Platform System Technology Study. The 
purpose of APSTS was to initiate the control and structure interaction study at the top 
level. The goal of APSTS was to establish guidelines for flexible space station attitude 
control system- design and to indicate viable technology options requiring further study. 

In the process of setting guidelines for control system design, APSTS intimated that low- 
band controller pass band would be limited to frequencies less than .10 Hz and most 
likely less than .01 Hz owing to the lowest solar array structural mode frequency. It was 
feared that if the free-free mode control bandwidth interacted with the flex mode 
dynamics, instability would result. Therefore a cutoff well below the lowest flex mode 
frequency would ensure stability with a performance penalty. However, the results of 
this study clearly show that flex mode stability is not an issue of concern when a 
reactive controller is used. Rather, the principle concerns with reactive control are the 
presence of structural modes with essentially no damping augmentation from the 
controller and the implications that accompany the sustained vibrations as previously 
mentioned. This study shows that the magnitude of undamped modal vibration can be 
reduced by increasing the system bandwidth. However there are obvious limitations 
owing to the accuracy which attitude can be determined. These issues will be discussed 
in the sections to follow. 

2.1.4 Overview 

In the following sections the technical approach to the analysis and simulation tasks 
along with a summary of the results and conclusions will be given. Section 2.2 presents 
the details of the technical approach used to conduct the study. First, a brief summary 
of the configuration selection process will be given. Then the subtasks will be outlined. 
Finally, the architecture of the software used for analysis and simulation of the selected 
configuration will be presented. Section 2.3 presents a detailed discussion of each of the 
elements effecting the attitude control system design. The elements include the struc- 
ture, controllers, disturbance inputs, and feedback control laws. A stability analysis of 
the closed loop system is presented, and the results are correlated with simulated time 
response data. Section 2.4 summarizes the results of the analysis and simulation tasks. 
Section 2.5 presents the conclusions of the study, and section 2.6 gives recommendations 
for continuing effort in the identification of technologies for space station attitude 
control. Section 2.7 provides a list of references. 
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2.2 APPROACH 

The technical approach is formulated in terms of five main tasks. These tasks are des- 
cribed in the discussion to follow. 

2.2.1 Formulate a Candidate Configuration 

The major elements required to formulate a candidate space station architecture are the 
class option categories, the functional attributes as defined by NASA and the set of 
governing assumptions. Class option categories refer to the premises that define the 
architectural concept. The two categories are the open class and the limited class. The 
premise for the limited class is "a space station as a permanently inhabited facility 
engaged in productive work and delivered to low earth orbit in stages the dimensions of 
which are consistent with the shuttle cargo bay". , The open class consider applications 
such as the use of the shuttle external tank, shuttle derived launch vehicle and tethers. 

The first step in the process was to select a class option. The configuration for the 
space station technology study was derived from the limited class premise with adher- 
ence to NASA governing assumptions. The details of the configuration selection process 
along with the set of NASA assumptions and groundrules are given in section 2.7, 
reference 1. 


The next step was to develop a schematic architecture consistent with the functional 
attributes and incorporating various strategies for growth leading to a 12-man configura- 
tion representative of shuttle deliverable hardware. 


The result was an evolutionary configuration that is controllable and functional as a 
space station. The attitude control study considered four operational stages that incor- 
porate two phases of assembly, with and without the orbiter docked. The two phases of 
assembly will include the initial habitable stage and the all-up fully operational stage. 

A pictorial view of the study configuration is shown in figure 2.2-1. A representative 
buildup sequence is shown in figure 2.2-2 along with the stages selected for analysis. 

The weight of the all-up configuration is 94000 kg with solar panels sized for 75 kW 
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Figure 2.2 - 1. Space Station Balanced Array Concept with 
Astromast Solar Array Deployment 



CONFIGURATION 0 

LOGISTICS + COMMAND + CREW QUARTERS ♦ SOLAR PANELS 
FIRST HABITABLE CONFIGURATION 

CONFIGURATION 0 

CONFIGURATION 0 ♦ REMAINING MODULES 
ASSUMES NO OTV OR PROPE LLANT TANKS 

Figure 2.2-2. Buildup Sequence Defining Configurations 
for Control/Structural Analysis 
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(actual). The total surface area of panels for 75 kW is 1100 square meters. The inertial 
and structural properties of the configuration will be presented in section 2.3. 

Initial configurations featured a cantilevered solar panel design, where the entire panel 
was pivoted at the end point. As the configuration developed the center pivoted 
balanced solar array concept was proposed as a configuration improvement for enhancing 
attitude control. The issue of achieving controllability through mass balance was the 
primary concern in the configuration of the center mounted solar panels. Mass balance 
was a principal design goal in order to ensure that CMG controllers will enable attitude 
stabilization with minimal expenditure of energy for momentum management. Dynamic 
balance is achieved by center pivoting the solar panels. The balanced configuration con- 
siderably reduces dynamic products of inertia for earth pointing that arise as the panels 
are tilted and rotated to track the sun line. Rotation of cantilevered panels induces very 
large periodic products of inertia at orbit frequency that create secular torques due to 
gravity gradient and Euler coupling. The center mounted solar panel also increases the 
lowest frequency structural mode by a factor of two, due to halving the length of the 
solar panel deployment mast. 

2.2.2 Determine Mass and Dynamic Properties 

A finite element model of the station was developed and the resulting mass and stiffness 
distribution of the structure was input to the NASA Structural Analyzer (NASTRAN). 

The output modal data from NASTRAN established the normal mode shapes and natural 
frequencies of vibration. 

2.2.3 Define Models for Simulation 

The second order equations of motion describing the forced vibration of the structure 
were cast in modal form using the mode shapes and frequencies from the NASTRAN 
model. Ideal CMG controllers and rotational motion sensors were colocated on the space 
station near the mass center. The controller configuration, torque distribution algor- 
ithms, and feedback control laws along with a model of the internal disturbance torque 
from crew activity will be described in section 2.3. 


D180-27935-2 


2.2.4 Develop Program Architecture for Simulation and Analysis 

The system of analysis programs for control and structure interaction analysis and simul- 
ation is shown in figure 2.2-3. The IAC (Integrated Analysis Capability) provides I/O 
data manipulation and storage for ail major system elements in an automated and inter- 
active fashion. The major system elements are NASTRAN, optimum regulator and con- 
trol of linear systems (ORACLS), and engineering analysis system (EASY). The synthesis 
of a controller for a flexible structure would proceed as follows. First, NASTRAN com- 
putes the flexible dynamics of the vibrating structure in terms of normal mode shapes 
and frequencies from a finite element model of the space station mass and stiffness 
distribution. Next, interface program INDA formats the NASTRAN dynamic model out- 
put for input to ORACLS. Programs using ORACLS subroutines generate the linear state 
space formulation of the rigid and flexible body dynamics along with the sensor output 
matrix that relates the sensor outputs to both rigid and flexible state variables (sec. 2.7, 
ref. 2). The system dynamics and sensor output matrix are then used in the design of 
attitude control regulator and feedback compensators in the time domain, using Linear 
Quadratic Gaussian synthesis. The feedback gain matrices computed from ORACLS 
routines along with the disturbance torque model and the system and sensor output 
matrices from ORACLS subroutines are input to EASY 5. Program EASY 5 is an engi- 
neering analyses system that computes the time response of a nonlinear system and has 
the capability of linearizing the nonlinear system about an operating point for the 
purpose of stability assessment and other linear time and frequency response analysis 
tasks. 

It is noted that the IAC was a pivotal factor in the successful completion of this work. 
High order models require very large data files that must be manipulated to effect con- 
troller design and analysis. Data and model files must be stored and retrieved for per- 
formance analysis and graphics presentation. In the absence of a fully automated inter- 
active I/O capability, the analysis and synthesis tasks of designing controller for realistic 
structural models is precluded. 

J 

2.2.5 Conduct Analysis and Simulation 

The analysis of attitude control system stability was performed by arguments based on 
the theory of positivity of operators (sec. 2.7, refs. 8 and 9). The basic stability theory 
was verified by frequency response methods and time response from simulation of the 
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Figure 2.2-3. Software Architecture Technical Approach 
for Dynamic Simulation and Analysis 
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closed loop system. The performance of the closed loop system was determined from 
time response data. System performance includes the motions of the central core and 
the flexible elements. Stress at the root of the solar array boom and astromast were 
derived from time response data. These calculations are especially valuable for evalu- 
ating structural integrity due to docking loads. 

2.3 TECHNICAL DISCUSSION 

2.3.1 Structural Model 


A finite element model was constructed using the NASTRAN computer program. The 
following is a description of the model. All components described are labeled in figure 
2.2-1. Section properties and dimensions are shown in table 2.3-1. 

2.3.1. 1 Solar Arrays 

The solar array booms were modeled as graphite/epoxy tubes, 24 meters long. The solar 
array astromasts were modeled as triangular trusses with a design by AEC-ABLE called 
Continuous-Longeron Able Boom. Sizing of the boom and astromast was done assuming a 
maximum static load of O.lg. The astromasts are housed in round cannisters at the end 
of the array boom. The solar array panels are stored in boxes at the near end of each 
panel and reinforced at the outboard end by a stiffer. Rods extend from the box to the 
stiffener along the center of each panel to simulate the cable along which the panel is 
deployed. 

2.3. 1.2 Modules 

The five modules were assumed to be rigid bodies with flexibility at their connection 
points with each other and with the orbiter. The stiffness at the ends of the modules was 
computed separately for the module and for the docking tunnel, then springs in series 
were assumed and the stiffness for the module including the docking tunnel was com- 
puted. The stiffness at the module side connection points was computed using equations 
for circular rings. 

2.3. 1.3 Mass Properties 

The mass properties of the space station were derived under the following assumptions. 
The masses of all the structural members are uniformly distributed along their lengths. 
The masses of the solar panels are lumped half at either end of the astromasts and mass 
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Material Properties 

Celion Fiber Cables E = 172E9 N/m 2 
5 Glass/Epoxy E = 52E9 N/m 2 , G = 6E9 N/m 2 

Graphite/Epoxy E = 108E9 N/m^, G = 15E9 N/m 
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moments of inertia are added to reflect the actual mass distribution. The module masses 
are lumped at their c.g.'s with moments of inertia to reflect the actual mass distribution. 

The mass of the radiators was lumped along the boom at either end of the radiator with 
moments of inertia included to reflect the actual mass distribution. The mass of the 
RCS thrusters was lumped at the outer end of each RCS boom. 

The space station mass properties for the test configurations with and without the 
orbiter docked are given in table 2.3-2. The principal axis basis vectors are the columns 
of matrix M. 

From the parameters given in table 2.3-1 and the dimensions shown in figure 2.2-1 the 
stiffness of the members in torison and bending can be computed from the relations, 

Ktor - G3 
L 

K flex = 3EI (concentrated load at x = L) 

L3 

where G and E are the moduli of rigidity and elasticity, 3 and 1 are 
verse area moments, L is the length of the structural member, and 
tional area. 

The stiffness equations for torsion and bending in table 2.3-1 were used to estimate the 
frequency and amplitude of oscillation for the elastic members as a check on the 
NASTRAN model. 

2.3.2 Structural Model Order' Reduction 

The order of structural model derived by finite element methods is theoretically infinite. 
In a practical sense the model is very large, the majority of the modes having negligible 
inpact on controller design. 


the axial and trans- 
A is the cross sec- 



Table 2.3-2. Mass Properties oi Space Station 
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(1) eg location with respect to node 100, the attach point of the solar panels, cf fig. 2.3-9. 

(2) The total mass of the solar panels is 1652 Kg. 

The total area of the solar panels is 1111 m*. 
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To provide ease of analysis and data handling the high order structural model must be 
reduced. The goal is to isolate those eigenvalues that have the greatest influence on the 
structure input/ output response. The method of impulse energy (sec. 2.7, ref. 3) is found 
to be effective in reduction of high-order models. The foundations of the theory for the 
impulse energy method are presented here. 

Given a high-order, linear, time invarient, asymptotically stable system in modal form, 
x = Ax + Bu 

y = Cx 

Simultaneously introduce unit impulses of the form u = & (t) into all controls. Com- 

pute the output impulse response energy. 

oo 

E = ^ y (t) y(t)dt = E ( "M,....,Xn) 

o 

For each eigenvalue \|< of the system matrix A compute the individual contribution 
E k(\k) to the total energy E. The eigenvalues Xk the largest Efc are usually retained 
for model reduction. The impulse energy analysis for the space station structure in con- 
figuration 1 is shown in figure 2.3-1. The analysis considered the presence of 80 modes 
of vibration up to 30 Hz which represents flexing of the raft structure due to compliance 
at the module interface. The semi log plot shows the relative energy contributions ex- 
pressed as the ratio (E max /E) for the first 28 modes up to .79 Hz. Values of 
log (E max /E) for mode numbers greater than 28 are all substantially greater than 1. 

Based on this analysis, the first 18 structural modes were retained for the simulation 
model. It is noted that the method of impulse energy gives a clear indication of those 
modes that can be affected by the given combination and placement of sensors and 
actuators. 

The mode shapes and frequencies of the truncated structural model for Ernax/ E<s 1 are 
shown in figure 2.3-2. These are the modes identified by impulse energy as being the 
most susceptible to control by core mounted actuators and sensors. The fundamental 
torsion and bending modes of all structural members are represented. The first astro- 
mast bending mode above the fundamental is present in mode 18. It is interesting to 
note that the highest impulse energy is contained in mode 16. This mode of vibration is 
dominated by array boom and astromast bending. From this observation, conclude that 
bending of the array boom and astromast are the flexible element motions most effi- 
ciently damped by the core mounted controller. Also note that mode 6 appears 


17 




Figure 2.3-2. Normal Mode Shapes and Frequencies for Modes in Truncated Model 
with Normalized Energy E mgx /E < 1 
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to be dominated by astromast torsion and to a lesser extent by bending. However, from 
figure 2.3-3 observe that mode 2 (modes 1, 3 similar) is exclusively dominated by astro- 
mast torsion. Therefore from impulse energy conclude that the principle energy contri- 
bution to mode 6 is from astromast bending and astromast torsion is not controllable 
with the core mounted actuators and sensors. These conclusions will be verified by the 
time response of the closed loop control system. It is also clear from mode 6 that bend- 
ing and torsion are coupled. Therefore a method for actively controlling astromast torsion 
with core mounted actuators is indicated and will be presented in the discussion of the 
control response results. 

It is noted in passing that the structural model made no mechanical provision for coupled 
bending and torsion of the astromast section. Recall that all the mass of the solar panels 
was lumped at either end with inertias included to reflect the mass distribution of a flat 
plate. Because inertia forces and torques act through and about the center of mass the 
observed coupling of bending and torsion in mode 6 is a model phenomenon and must not 
be linked to a direct mechanical cause and effect. Future models of the astromast sec- 
tion will include inertia forces of the solar panels that are offset from the section cen- 
troid, producing torsion as the mast bends. 

2.3.3 Controller /Sensor Selection 

The controllers selected for the space station simulation are a multiple grouping of Sky- 
lab class two axis double gimballed control moment gyros in a parallel mounted con- 
figuration. A schematic of the configuration is shown in figure 2.3-4. The two axis 
double gimballed CMG is ideal for applications where rate loop bandwidth is not essen- 

9 

tial. In this instance there is a greater demand for H than H and the two axis gyro 
approximates a position controller. 

The parallel mounting configuration provides a very simple gimbal angle steering law. In 
addition, hardware mounting, redundancy management, and failure accommodation are 
greatly simplified. The parallel mounting steering law provides reduced rate require- 
ments on the outer gimbal and avoids singularities internal to the angular momentum 
envelope. The gimbal angle control laws were taken from reference 4 in section 2.7. 

For reference, the distribution of gimbal angles and rates for a typical closed loop 
response to an impulsive disturbance is shown in figures 2.3-5 and -6. 
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It is noted from figures 2.3-5 and -6 that the initial position of the outer gimbals is such 
that all H vectors are 120° apart. This distribution produces zero net momentum state 
in spacecraft coordinates which is advantageous for multiple CMG applications to earth 
oriented vehicles. 

The dynamics of the CMG's were neglected in this analysis because the bandwidth of a 
Sky lab class two axis gyro is approximately 10-20 Hz. The bandwidth of the attitude 
control system is expected to be less than .50 Hz. The phase contribution from a 20 Hz 
actuator at rate loop crossover is therefore negligible. The motion variables of the free- 
free modes (attitude and attitude rate about the center of mass) were assumed to be 
derived from a measurement algorithm, for example, quaternion integration where the 
bandwidth of the process can be assumed large with respect to the attitude control 
system. 

2.3.4 Disturbance Input Profile 

The disturbance profile for modeling crew activity is shown in figure 2.3-7. The model 
represents an astronaut in a soaring maneuver within the space station. A detailed des- 
cription of crew disturbances is given in reference 5 in section 2.7. The motion is 
envisioned as being a pushoff from one wall and a deceleration at the far wall. The para- 
meters for the motion are presented for a large astronaut in the flight within a module 
of about 12 ft in diameter. The resulting impulsive momentum disturbance is 400 
n-m-sec for each element of the doublet. To establish a highest upper bound from all 
internal sources including mechanical equipment a value of T 0 = 1000 n-m was used as a 
worst case value for simulation and analysis. 

The worst case level was derived by considering all the internal disturbances from the 
major sources including crew motion. Table 2.3-3 summarizes the momentum contribu- 
tions from liquid transfer, rotating equipment and crew activity. An upper bound of 1000 
n-m-sec seems reasonable. 
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Figure 2.3-6. Closed Loop Controller Response to 1000 N-MSec Impulse 
Doublet in Pitch and Roll for Con figuration 2 
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Table 2.3-3 Internal Disturbance 


SOURCE 

DIST. 

MOMENTUM 
(N— m— s) 

Liquid 

Transfers 


OTV Fuel 
Transfer 

200 

Cooling 

Loop 

Rotating 

Equipment: 

100 

CELSS 

300-500 

Medical 

800 

Crew 

Activity 

400 


2.3.5 Simulation Results 


The simulated response of the structure to the single test disturbance impulse doublet 
was computed for both open loop and closed loop cases. The resulting time responses are 
shown in figures 2.3-11 to 2.3-16. Figures 2.3-11 to 2.3-14 give open and closed loop 
responses side by side for easy visualization of the effect of the controller on the 
disturbed system. The block diagram for the closed loop system representing an attitude 
regulator is shown in figure 2.3-9. The nodal structure indicating the nodes used to 
extract measurement data is shown in figure 2.3-8. Motion of the core structure relative 
to an inertial frame was extracted from the rotational state of the variables $ , 0 , $ 

(roll, pitch, and yaw, about x, y, z) of node 100. Measurements of flexible element 
motion relative to node 100 are specified as follows. These rotational measurements 
indicate the flex and twist of the solar panel boom and the astromast structure, 
m Bx = Flex °f panel boom ($100-105) 

= Twist of panel boom (0100-105) 

= Flex of panel boom ($100-105) 

= Twist of the astomast ($100-323) 

Mi = Flex of the astomast (0105-323) 


M By 

M Bz 

Ma* 
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VECTORS DISTRIBUTION MATRICES 

u - TOTAL TORQUE A - CMC TORQUE 

£ - MODAL COORDINATE B - CONTROL INPUT 

y - MEASUREMENT C - MEASUREMENT 

f - FEEDBACK TORQUE 0 - MODAL STATE (EIGEN VALVE) 

COMMAND if - EIGENVALUE DIAGONAL 

K - FEEDBACK CONTROL 

Figure 2.3-9. Generic Block Diagram of an Attitude Regulator for a Flexible Structure 



Figure 2.3- 10. Orbiter Docking to Space Station Showing Preferred Configuration 
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The quantities ^,^ 0 , ^represent the contribution of the flexible modes to the total 

attitude response. For example 0 = 0 f + £q is the total rotational response of node 100 

about the pitch axis and 0f is the component due to the free - free motion only. It is 

noted that quantities Mg , Mn , and Ma represent the mode slopes at the end of the 

x z y 

associated flexible members. All response quantities in figures 2.3-11 to 2.3-16 are in 
arc -sec. 

2.3.5.1 Open Loop Response 

The uncontrolled response of the structure to the test disturbance in the pitch and roll 
axes is shown in figures 2.3-11, 12, 13, 14 and 15 for configurations 1 and 2. In the pitch 
axis the contribution of flexibility to core rotation about y, e Qis dominated by twist of 
the solar array boom as evidenced by inspection of Mgy and of figures 2.3-11 and 
2.3-13. Reference to figures 2.3-12 and 2.3-14 show that in roll the rotation of the core 
station due to flexibility, £<J>, is attriuted to flexing of the astromast about y as seen in 
MAy. The induced bending of the boom, shown in Mb z , is reflected directly into 
Inspection of Ma x and comparison with ^,2^ indicates that astromast twist has negligi- 
ble impact on lateral motions as expected. The coupling of astromast torsion through 

flexing is clearly seen by comparing Ma and Ma v for pitch and roll responses. The 

x y 

inertia effect is clearly indicated by comparing the responses for configurations 1 and 2 . 

The response of the structure to a typical orbiter docking from impact loading at body 
station 1201 only is shown in figure 2.3-15. It is assumed that the orbiter has an initial 
rotational rate at docking about its c.g. of = .2 deg/sec. with a linear velocity of 
v o = 0.15 m/sec as shown in figure 2.3-10. assuming the centerline of shock is 1 meter 
from the station c.g. and further assuming that the collision is perfectly elastic, the 
resulting impact will impart approximately 2500 N-sec to the station. For the deflec- 
tions shown in figure 2.3-15, the minimum factors of safety in terms of stress at the • 
beam root are at least 100 in both astromast and array boom bending and torsion. 

The max deflection Mb z (figure 2.3-15) was estimated analytically and found to be 
within 10% of the simulated value. Therefore the simulation was found to be trust- 
worthy giving additional confidence in the interpcetation of the modal quantities that are 
output from the structure dynamic equations computed through the IAC. 
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2.3. 5-2 Closed Loop Response 

The simulated response of the attitude regulator to the test disturbance is shown in 
figures 2.3-11, 12, 13, 14, and 16. The system bandwidth chosen for presentation is .05 
Hz for all configurations except .25 Hz for configuration 2. The controller was a simple 
proportional plus derivative feedback of free - free mode attitude measured at node 100 
(see fig. 2.3-8). The time responses indicate that regulated free - free mode attitude is 
both stable (in accordance with theoretical predictions) and controllable. The control- 
lability of the structure is not surprising because the impulse energy analysis has clearly 
indicated that controllable normal modes contain motions of all structural elements with 
the exception of twist of the astromast. The time responses support this claim and would 
indicate that torsional vibrations of the astomast are not controllable with the control- 
lers and sensors mounted oh the rigid core as expected. 

Recall from the impulse energy analyses that vibrations associated with antisymmetric 
mode 16 showed the highest potential for suppression by the core mounted controller. 
Array boom and astromast bending are the principle components of mode 16 and the time 
responses clearly show that boom and mast bending vibrations are effectively suppressed. 
However, although antisymmetric mode 4 shows relatively high impulse energy the tor- 
sional vibrations in the boom are not as well damped as boom and mast bending vibra- 
tions. Note that the pitch axis response exhibits almost pure mode 4 response. Normal 
mode 4 is dominated by boom torsion and the mast seems to move as if it were rigid (cf 
M^y, MBy> figs. 2.3-11, -13). Although the flexible state variables associated with this 
mode are very controllable, they are weakly observable in the output as expected, which 
accounts for the low relative damping of boom torsional vibrations relative to boom and 
mast bending vibrations. 

It is noted that the rate of suppression of vibration (damping) in the structural elements 
appears to be independent of vehicle inertia for fixed free - free mode control band- 
width. However, the magnitude of the vibration is of course inversly proportional to 
vehicle inertia as expected. The damping of structural vibrations for a given vehicle 
inertia decreases with increasing free-free mode control bandwidth, c.f. figures 2.3-13, 
-14, and 2.3-16. This is due to the fact that with increasing bandwidth the closed loop 
modal poles approach the open loop modal zeros that are virtually undamped. The result 
is that the residual in the response due to a given modal pole is reduced but so is the 
closed loop damping on that pole. 
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2.3.6 Stability Theory 

The block diagram for discussing the stability of a structure with colocated sensors and 
actuator is shown in figure 2.3-8. A formulation of the structure equations and the 
theorem relating to the nature of the controller required for attitude stabilization is 
stated here. 

Given the undamped structure dynamics in modal form 


•• 2 

K + fl £ 




with state vector x = 




, system eigenvalues, 



v 


and system eigenvectors, $ = 





Given that the feedback is of the form f = Ky where Kp and K r are the position and rate 
gain partitions of matrix K. 


then, if ideal sensors (C) and actuators (A) are colocated anywhere on the structure then 
= c and a controller of the form 



e 1 " * .0 

o a T $ 


x 


stabilizes the attitude of the multi-input, multi-output structure. The gain of the CMG 
torque distribution matrix is unity. Ideal sensors and actuators have no phase associated 
with their operation and are said to have infinite bandwidth. The theorem is proven for 
single-input, single-output system in section 2.7, reference 7 and was derived generally 
for the multi variable case using positivity arguments from references 8 and 9 in section 
2.7. 
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2.4 SUMMARY OF RESULTS 

The important control/structure interaction issues for a representative space station 
configuration have been addressed. Specifically, the stability and performance of the 
station with a core mounted linear controller has been investigated. The inertias are of 
order 10^ with solar panel size of 1100m2 which is consistent with a 75 kW power 
requirement. The following statements summarize the results of the study. 

1. Analysis has shown and the simulation has verified that the raft configuration is 
stable and controllable when ideal sensors and CMG actuators are colocated. 
Because the raft is rigid at frequencies of interest (0.5 - .5 Hz), colocation of ideal 
sensors and actuator on the raft will guarantee stability. 

2. Damping of the structural modes is substantially augmented in most cases by the 
CMG core mounted controller. Damping of astromast torsional vibrations is not 
augmented by the core mounted controller. 

3. The performance of the ideal reactive controller in terms of its ability to suppress 
transient disturbances at levels of practical interest, is limited only by the control 
authority. The issues addressed in the current simulation work are therefore related 
to the assumption of ideal (infinite band width noise free) sensors and actuators. 

4. Simulation shows no extreme motions of flexible elements when subject to the most 
severe shocks due to docking loads. The loads were modeled as impact forces at the 
docking interface. The max stress at the root of the array beam and astramast are 
at least a factor of 100 less than the proportional limit stress. 

5. Gimbal rate response to the test impulse doublet was found to be as high as 6°/sec 

for controller bandwidth of .05 Hz. Skylab class gyros are rate limited to 4-6°^ se ^' 
Therefore if bandwidth above .05 Hz is required for the class of space station 
studied here then three Skylab gyros is the minimum number to insure accuracy of 
100-200 arc sec under the assumed level of transient loads. 
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2.5 CONCLUSIONS 

The purpose of the study was to evaluate the basic stability and pointing performance of 
the core station when perturbed by impulsive disturbances that were intended to model 
torques produced during a productive work cycle. At the outset of the study, it was 
surmised that attitude stability might be jeopardized when the control band interacted 
with the flex modes. However, the theory shows that when the core station can be 
assumed rigid with respect to the control bandpass then the controlled response is' 
asymptotically stable when the sensors and actuators are colocated anywhere on the 
core. A simulation of the flexible station and a control system consisting of multiple 
two axis double gimballed CMGs ideal attitude sensors was implemented. The attitude 
response of the system to impulsive disturbance verified the stability theory and showed 
substantial improvement in modal damping in most cases. 

The conclusion of the study can be summarized as follows. Control of the free - free 
attitude modes using a regulator consisting of colocated CMG actuators and ideal rate 
and position sensors is asymptotically stable. However, the response of flex modes asso- 
ciated with the astromast is lightly damped with long settling time. If the resultant low- 
amplitude vibrations are objectionable, then flex mode damping must be introduced. 
Investigation of passive damping techniques should be a first priority. With these results, 
the important issues of core station free -free mode attitude control using a simple con- 
troller without additional stability augmentation of the flex modes has been addressed. 

Alternate technologies for attitude control were intended to supplant the low-band con- 
troller in the event that attitude stability and performance were degraded. Analysis has 
demonstrated that the space station is attitude stable and performance is questionable 
only to the extent that low-amplitude vibrations of the structure are lightly damped. If 
the persistent low-amplitude, attitude oscillations are objectionable, then additional 
damping must be introduced. Investigation of passive damping schemes reveal that these 
techniques might be applied to the solar panel boom to dissipate the energy of the flex 
modes. Damping on the order of 10% has been demonstrated in laboratory experiments. 

2.6 RECOMMENDATIONS 

Continuing effort in attitude control for space station should concentrate on defining 
control requirements during buildup and construction phases including configuration with 
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the orbiter docked. Emphasis should be given to definition of control modes for each 
phase of evolution and schemes for managing the momentum envelope of candidate 
momentum transfer systems. Control modes would include electromagnetic sensing and 
actuation, momentum transfer, mass expulsion, attitude biasing, and appendage 
articulation. 

During the configuration development phase of the previous study emphasis was given to 
achieving a dynamically balanced design. Mass balance will ensure that momentum 
transfer devices can be used for control Without excessive propulsion requirements. All 
previous structural models will remain intact and no redesign of core station or append- 
ages will be required to accommodate mass balancing. The space station configuration 
developed for this study will therefore be used without modification for evaluating can- 
didate controllers for the proposed continuing effort. The simulation will be modified to 
include the control laws. 

The output of the proposed study will be a control mode survey and trade off evaluation. 
Based on the results of the evaluation, recommendations will be made regarding the most 
effective attitude control strategy for space station during its evolution and long term 
operation. It is expected that the resultant control strategy will be synthesized from a 
set of technology elements already in place. The challenge will be to find new and crea- 
tive applications for the basic elements with suitable modifications to the control laws 
that reflect modern computational techniques. 
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3.0 DATA MANAGEMENT 

The data management section of this study was concerned with the data processing, 
storage and communications hardware and software that comprise the Space Station 
Data Management System (DMS). The study approach, analyses, and results are 
described in the following paragraphs. 

3.1 INTRODUCTION 

Data management includes the data system hardware and software needed to provide all 
Space Station data processing, storage and communications for onboard users, subsys- 
tems and payloads. This study was based on requirements determined in the previous 
study phase as shown in figure 3.1-1, and extended that work in three main areas. The 
first area is mission configuration analysis from a data management point of view; the 
second is the electronic hardware needed to provide data management services; and the 
third is the data management system software. These areas were addressed as three 
subtasks in this study. 

Section 3.2 describes the study approach, followed by a technical discussion in section 
3.3. The study results are summarized in section 3A, and conclusions and recommenda- 
tions are presented in sections 3.5 and 3.6 respectively. 

3.2 APPROACH 

Data management is an extremely broad study area because twenty or more Space 
Station subsystems, dozens of payloads and experiments, crew stations, computers, data 
storage devices, and communications transceivers are ail interconnected through the 
data management network. The main function of data management is the integration of 
data from such equipment and subsystems to provide an effective, flexible, expandable 
and high performance transfer of information. The onboard system will be targeted 
toward a high degree of autonomy, but on the early space station, ground control, 
ground-based users, and other orbital platforms will also be connected through the DMS. 
The on board DMS, therefore, will be a cluster of computer-related equipment and soft- 
ware, within a much larger end-to-end data network. These considerations led to the 
conclusion that the DMS could be regarded primarily as a local area network (LAN). The 
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SUBSYSTEM 

PROCESSING CHARACTERISTICS 

STORAGE REQUIREMENTS 

COMMUNICATIONS 

BANDWIDTH 

CONTROL 

FAULT TOLERANT COMPUTING 
SENSING. FILTERING ETC 

SMALL ARCHIVE 
SMALL BUFFERS 

<1 MBPS 

COMMUNICATIONS 

SWITCHING/MULTIPLEXING 

LARGE BUFFERS 

>100 MBPS 

DATA BASE 

SEARCHING & SORTING 

LARGE ARCHIVE 

< 100 MBPS 

DISPLAY 

IMAGE GENERATION 
& SWITCHING 

LARGE ARCHIVE 
LARGE BUFFERS 

> 100 MBPS 

MAINTENANCE 

AUTO-TEST & SIMULATION 

LARGE ARCHIVE 

< 10 MBPS 

MANIPULATOR 

SENSING & MOTOR CONTROL 

SMALL BUFFER 

< 1 MBPS 

SPACECRAFT TEST 

SIMULATION & SWITCHING 

LARGE ARCHIVE 

>100 MBPS 

EXPERIMENT* 

SENSING & SWITCHING 

LARGE ARCHIVE 
LARGE BUFFERS 

>100 MBPS 

AUDIO 

DISTRIBUTION 

A/D & D/A CONVERSION 

SMALL BUFFERS 

< 10 MBPS 

VIDEO 

DISTRIBUTION 

ANALOG SWITCHING 

NONE 

>100 MHz 
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Figure 3. 1-1 Data Processing, Storage and Communications Requirements 
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LAN concept, identified during the previous study, has been expanded here to include 
details of the LAN architecture. 

The purpose of the mission configuration analysis subtask, which is the first subtask of 
the data management trade studies, was to assess the impact of candidate Space Station 
missions on the DMS and to ensure that the concepts developed in the previous study 
would meet requirements from those missions. This analysis was used to develop a model 
of the DMS for future simulation studies, and also provided an input to subtasks two and 
three. The network interface unit (NIU) and network operating system (NOS) were 
identified in the previous study and a cost -benefits analysis was conducted to determine 
their potential value to the program. It was estimated that a savings of $176M could 
potentially be realized if the LAN were developed, prior to space station development, 
and if the onboard subsystems and payloads of the station used the LAN hardware and 
software for data collection, processing, storage and communications. The higher cost 
alternative would have each experimenter develop his own DMS interfacing hardware and 
software, followed by a systems integration step to make the payload compatible with 
the onboard data management system. This approach results in needless duplication of 
effort, when compared to the LAN. Also, the savings of $176M refers only to develop- 
ment costs. It is believed that the LAN would also yield significant savings in 
operational costs, due to the ease of maintenance resulting from its standardized, 
modular organization and, due to the reduction in logistics requirements brought about 
by the use of a small set of common modules. 

After completion of the mission configuration analyses, the impact on the DMS hardware 
and software systems could be assessed more readily. This permitted the primary hard- 
ware element of the DMS to be analyzed and described in greater detail, as subtask 2; 
with the primary software element defined functionally, as subtask 3. -These elements 
are the "Network Interface Unit" (NIU) and "Network Operating System" (NOS), 
respectively. 

The studies described above provided the basis for the identification of DMS technologies 
and task 2 of the study provided a cost and criticality analysis of the several technology 
items or areas identified. The approach taken in task 2 was to evaluate the role of each 
item or area from the perspective of the overall Space Station program. This involved 
estimates of relative need by the program, lead time, cost for development, and where 
possible, estimated value over the life of the Space Station. The most critical items are 
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those that are needed early in the program, that also have long lead times. This concept 
of need versus lead is explained more fully in section 3.4. 

Task 3 was the preparation of technology advancement plans and the results of that task 
are reported in volume III. 

3.3 TECHNICAL DISCUSSION 

This section describes the technical content of the data management portion of the 
study. Because this was an extension of a previous study, some background material will 
be presented in each portion for clarity and continuity. 

3.3.1 Mission Configuration Analysis 

The identification of Space Station mission requirements on the DMS considered data 
communications bandwidths, data storage capacities, processing requirements, and inter- 
facing requirements imposed by the experiments. Three example mission models were 
investigated, each having different data management requirements. These include Con- 
struction and Materials Processing Station (CAMPS), Communications and Data Man- 
agement Station (CADMS), and Land, Ocean, and Atmospheric Research Station 
(LOARS). 

CAMPS would be used for the construction of large space structures and spacecraft, plus 
production of semiconductors, alloys, and pharmaceuticals. Capabilities required in 
addition to a basic DMS functions might include data handling for teleoperators, robots, 
and a variety of remote sensors and effectors for construction purposes. The materials 
processing payloads would require automated process control capabilities, which would 
also require data management. 

CADMS would provide command, control, and communications support for onboard and 
free-flying payloads and experiments. It would have powerful signal and data processing 
capabilities that could be shared by many experiments or spacecraft through a space- 
based communications network. It would use large high-speed data storage devices such 
as laser disks for archival storage of data generated and utilized on-orbit. 
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LOARS would be used primarily for remote sensing of weather, crops, sea state, and 
other planetary conditions and phenomena. It would carry high-resolution, high-band- 
width imaging sensors such as the Landsat-4 thematic mapper, and the Seasat synthetic 
aperture radar (SAR), but in more advanced versions. Such devices would place very high 
requirements on the data management system, providing a kind of worst-case DMS 
scenario. Therefore, LOARS was investigated in the greatest detail. 

In the Advanced Platform Systems Technology Study (APSTS), a DMS configuration 
concept known as the fiber-optic backbone network was presented. This is a local area 
network suited for use aboard the Space Station because it is defined to have high 
reliability, maintainability and performance, while preserving an excellent potential for 
future expansion. This concept is defined to use digital baseband packet switching, as 
opposed to broadband or wavelength-division multiplexing. Broadband systems typically 
use a remodulator to establish connections between transmitters on one set of 
frequencies, and receivers on another. Broadband systems are vulnerable to single-point 
failures at the remodulator, and they require periodic adjustments to their analog and RF 
circuitry, making them unsatisfactory for use aboard the station. Wavelength division 
multiplexing systems typically require laser transmitters and optical multiplexers and 
demultiplexers. They have advantages over long fiber runs of a kilometer or more 
because many channels can be multiplexed onto a single fiber with considerable cost 
savings. But, over short distances such as aboard the station, the savings in optical fiber 
are insignificant and do not justify the expense and complexity of lasers and optical 
multiplexing equipment. 

Figure 3.3-1 shows how the backbone network might fit into a space station configura- 
tion called the raft structure. The heavy lines are bundles of optical fibers, that inter- 
connect the network interface units, or NIUs. The NIUs are modular electronic units, 
discussed in later sections, that house interface modules for the various digital and 
analog electronic devices carried aboard the station. Input data generated by these 
devices, such as high-bandwidth sensor data, are acquired by the NIU interface modules, 
stored temporarily, formatted, and routed to specific destinations by means of digital 
electronic communications or packet-switching. Specific destinations are addressable, 
depending on the application. Disk or tape storage devices, tracking and data relay 
satellite system (TDRSS) transmitters, and crew consoles are examples of output devices 
connected to NIUs. 
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Figure 3.3- 1 Fiber-Optic Backbone Network 
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The NIUs also support and control local data buses within each of the station modules. 
These buses could be standard serial buses such as the MIL-STD-1553B; however, present 
technology allows the use of higher speed buses, operating at 10-25 million bits per 
second (MBPS), such as the IEEE-802 proposed standard bus. Medium-speed devices, 
rather than high-speed sensors, would be connected to these buses. For example, small 
Winchester disk units typically operate at 10 MBPS, and several could be distributed 
about the station by connecting them to buses supported by different NIUs. This would 
provide a relatively low-cost, high-performance data base, that could be expanded 
almost at will by the addition of disk units. 

This topology can be described as a two-level hierarchy. The NIUs and their intercon- 
nections provide for communications between station modules, and form the upper level 
of the hierarchy. The devices connected to the links and buses within the modules, sup- 
ported by the NIUs, form the lower level. This approach allows for modularity at both 
levels. The NIUs handle inter-module communications through standard berthing-port 
interfaces, allowing station modules to be plugged-in at any berthing port. At the lower 
level, sensors and medium-speed devices can be plugged into the NIUs by means of stand- 
ard interface cards and standard buses. 

Multiple optical fibers are used for intermodule communications for several reasons. 
First, optical fibers have such a large potential bandwidth for existing and projected data 
communications applications that the same fiber bundles and connectors could be used 
throughout the lifetime of the station, although the NIU optical transmitters and 
receivers might be retrofitted at some future date. Second, the use of multiple com- 
munications channels provides for fault -tolerance, in the event of a hardware or soft- 
ware system failure. Third, optical fibers are nonconductive, and eliminate many 
potential problems with electromagnetic interference (EMI), ground loops, sneak circuits, 
or other undesirable electrical phenomena. 

Fiber-optic technology is now mature enough to be used on board the station for most 
data communications applications, especially if light-emitting diodes (LEDs) are used as 
optical sources instead of laser diodes, and if PIN diodes are used as optical detectors. 
Laser diodes have a higher power output than LEDs, but they are not as readily available 
and have much shorter operating lifetimes. The lower output power of LEDs is not 
necessarily a problem if point-to-point communications links are used, or if the number 
of ports driven by the transmitter does not exceed a maximum of 20-30 in an optical 


46 



D1 80-27935-2 


star-coupled configuration. Technical details on this topic are covered in the final 
report from the APSTS. 

At least two fiber-optic backbone network topologies are viable for space station 
application and are shown in figure 3.3-2. The set of lines drawn above the boxes 
represents the interconnection topology formed by the use of four optical star couplers, 
located near NIUs C, D, E, and F. For example, the coupler located at NIU-C inter- 
connects A through E, as shown by the lowest horizontal line. In this example, each of 
the couplers would interconnect a subset of five of the eight NIUs, so four five-port 
couplers would be required to assure a minimum of two redundant paths per NIU. The 
set of lines drawn below the boxes represents a point-to-point interconnection topology. 
Each link consists of a bidirectional channel, using two fibers with transmitters and 
receivers at opposite ends. Store-and-forward communications techniques are used, as 
opposed to the shared-bus techniques needed for the multi-star topology. 

Data packets are multiplexed by means of time division multiple access (TDMA) 
techniques, so that multiple data streams can share each channel. This approach 
requires that a store-and-forward capability be provided at each NIU, so that packets 
can be received and retransmitted by intermediate NIUs in a series of hops to the final 
destination. This naturally provides for fault- tolerance because one or more alternate 
routes can be provided for use in case of a failure at one of the NIUs. Another 
advantage is the low optical power requirement for transmission across a point-to-point 
link. The transmitter must drive only a single optical fiber, with a single receiver. 
Therefore, both the optical source and the detector can be extremely small, simple, 
reliable, and low in cost. 

The other viable fiber-optic topology uses multiple optical star couplers to interconnect 
the NIUs. It can be thought of as a multiple bus topology, with the star couplers provid- 
ing the shared bus media; or, it can be regarded as an active-repeater system, with the 
NIUs functioning as the repeaters. From either viewpoint, the system is more complex 
than a simple passive star-coupled topology. The star couplers are each associated with 
an NIU, with several other NIUs attached at the ports. In this configuration, only a few 
ports would be needed at each coupler, perhaps five, so the optical power requirements 
would be quite low, allowing the use of LEDs as optical sources. This topology also pro- 
vides fault-tolerance because each NIU has access to multiple star couplers, providing 
alternate communications paths in the event of a failure. 
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RAFT CONFIGURATION 
INTERCONNECTIONS FOR MULTI-STAR (4) 



INTERCONNECTIONS FOR GRAPH 


• BOTH TOPOLOGIES REQUIRE 20 OPTICAL TRANSCEIVERS 

• BOTH NEED ROUTING AND RECONFIGURATION CAPABILITIES 

• MULTI-STAR USES SHARED-BUS PROTOCOLS 

• GRAPH USES TIME-DIVISION-MULTIPLE-ACCESS (TDMAJ 

Figure 3.3-2 Multi-Star Versus Graph Topologies 
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With either topology, a reconfiguration capability is needed in the NIUs so that alternate 
links or couplers can be selected in the event of a failure. In both cases, the NIUs must 
be able to store and forward messages or packets, because multiple couplers or links are 
provided, and the NIUs are not directly connected to each other by means of a single 
common bus. Both configurations can use LED sources, and PIN diode detectors. The 
transmitter and receiver logic needed is essentially the same in both cases, as shown in 
figures 3.3-3 and 3.3-4. These figures are block diagrams of the functions needed to 
implement optical transmitters and receivers, with the exception of the control logic. 
The transmitter converts digital data residing in memory to a serial bit-stream, encodes 
it with clock information, and uses the resulting signal to modulate an optical source. 

The receiver uses an optical detector to convert the signal back to an electrical form for 
decoding and conversion to a parallel word format that can be stored in a memory 
buffer. These examples use a 32-bit memory and a 100 MHz serial data rate, so the 
required memory cycle time (320 ns) would be relatively slow. 

The two configurations use different access protocols for multiplexing the communica- 
tions media. The graph topology uses simple TDM A, while the multiple-star topology 
may use polling, contention or token-passing. In a polling system, one of the NIUs 
functions as a controller, polling each of the other NIUs in sequence to enable them to 
transmit data on a given bus, one after the other. In a contention scheme, each NIU acts 
independently and "listens" for activity on the communications channel. If the channel is 
not busy, the NIU can transmit; however, two may transmit almost simultaneously, 
resulting in a collision. They must detect such bus contention, back off, and try again 
after a random delay interval. In a token-passing configuration, the system is initialized 
so that one of the NIUs "owns" a logical token that enables it to transmit a packet. 

After completing its transmission, it then sends the token to another NIU, which may 
transmit and then pass the token to the next NIU in sequence. 

At this point, no clear reason exists for choosing either a pure graph or a pure multiple- 
star topology over the other. Communications network simulation studies are needed 
before a final configuration can be chosen. The next section describes the NIU concept 
in greater detail. 
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ENCODED BIT-SERIAL OUTPUT 
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Figure 3.3-3 NHJ: Transmitter Block Diagram 
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Figure 3*3-4 MU: Receiver Block Diagram 
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3.3.2 Network Interface Unit Internal Organization 

As shown in figure 3.3-5, the NIU is defined as a set of standard circuit cards that plug 
into a high-speed parallel data bus, housed in a rack-mountable chassis. The cards pro- 
vide high-speed sensor control and data acquisition interfaces, instrumentation bus inter- 
faces, fiber-optic intermodule communications transceivers, and many other types of 
input-output (I/O) interfaces and controllers. A set of standard modules can support a 
great many applications such as data acquisition through analog/digital converters, dis- 
crete I/O functions such as indicator lamp illumination or switch position-sensing and 
man-machine interfacing by means of keyboard and CRT controllers. Customized 
modules can also be added to the NIUs to support subsystems, payloads or specialized 
sensors. 

A central processor unit (CPU) with associated memory is also shown in figure 3.3-5. 
Conceptually, this might be a high-performance 32-bit microprocessor if its only func- 
tion is control of the NIU. However, multiple processors could also be installed in the 
NIU or connected to it through interfaces, to handle the onboard data processing tasks. 
Some of these could be specialized signal or image processors, or floating-point array 
processors, if they are required for onboard applications. 

The main design conclusions reached as a result of this study are that the NIU should be 
modular, and should have a high performance potential. Space Station requirements will 
surely change over a period of many years. The basic NIU chassis and high-speed parallel 
bus can support such changes and upgrades if they are designed with flexibility in mind. 
The bus should have a 32-bit data path, with a minimum capability to transfer data 
words at a 16MHz rate. At 512 MBPS (32 * 16MHz) this bus has a bandwidth about five 
time greater than a super-minicomputer bus (e.g., VAX-1 1/780) of today. This is enough 
capacity to handle approximately 20 compressed digital TV channels, or thousands of 
digital voice channels. It is possible that future high-speed devices could generate data 
at higher rates, but such applications may be quite rare, and could be served by cus- 
tomized interface modules that handle data without involving the NIU bus. 

Development of NIU modules would be a major project, because a dozen or more stand- 
ard electronic interface modules would have to be specified, designed, and fabricated to 
meet most of the potential station applications such as data acquisition or subsystem 
interfacing. 
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1. MODULAR NETWORK INTERFACE UNIT 

2. STANDARDIZED INTERFACE MODULES 

3. HIGH-SPEED INTERNAL PARALLEL BUS 


Figure 3*3-5 NIU: Internal Organization 
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Twelve such modules have been identified this far and they are listed as follows: 

1. NIU control processor and cache memory. 

2. Fiber-optic communications transceiver. 

3. Instrumentation bus interface controller. 
k. RF communications transceiver interface. 

5. Digital voice communications interface. 

6. Crew station console/CRT interface. 

7. High-speed sensor data buffer. 

8. Magnetic tape mass memory controller. 

9. Magnetic disk mass memory controller. 

10. Color video & graphics I/O controller. 

11. Analog I/O interface. 

12. Discrete digital parallel interface. 

Figure 3.3-6 shows how typical DMS modules might be supported by the parallel and 
serial buses. High speed devices such as a CPU or a video interface would be installed in 
the NIU chassis and connected to the internal bus backplane or motherboard. Low and 
medium speed devices would be attached to the serial buses. Each NIU could be -configu- 
red differently to support the equipment or applications within each station module; 
however, each would have a control processor and fiber-optic transceivers for network 
comm unications. 

Other custom modules would also be needed for specialized applications such as high 
speed sensors. The software needed to provide DMS services (i.e., network operating 
system) would also require a major development effort, and should be done in conjunction 
with NIU development. 

3.3.3 Network Operating System (NOS) 

An operating system is the collection of software processes that control computer sys- 
tems, as shown in figure 3.3-7. In a distributed system environment, or in a local area 
network, the term "network operating system" is frequently used, and has been adopted 
here. Aboard the Space Station, the NOS is conceived to have two major functions. 

First, it provides the operating environment for users of the DMS. Second, it manages 
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(EACH BOX REPRESENTS SOFTWARE RUNNING ON A SEPARATE PROCESSOR) 
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Figure 3.3-7 Network Operating System Example 
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the overall operation of the devices attached to the network, supporting status moni- 
toring and control functions, and providing data storage, communications and processing 
services. 

The NOS does not necessarily control the station systems or subsystems. Such functions 
depend on the NOS for computational support, and for control of interfaces, displays, 
keyboards and other devices that are used to operate the onboard systems. The actual 
control software for the various subsystems may be embedded in the devices, or may run 
on the applications processors provided by the DMS. Either way, the NOS is only 
indirectly involved in control of station subsystem application tasks. However, the NOS 
directly provides the user operating environment, as with any other kind of computer 
system. That is, in order to use the Space Station DMS resources, the crew, ground con- 
trol engineers and operators, and remote scientific users will have to interact with the 
NOS. The user will enter commands by means of a console keyboard and display device, 
and will receive responses or status reports from the NOS by the same means. For 
example, commands would be entered to activate a synthetic aperture radar, steer its 
antenna to a given azimuth, acquire data for a given interval, process that data to 
generate high-resolution imagery, display the image on a video monitor, store it on a 
video disk, and downlink it to ground-based operators or investigators. Such a compli- 
cated sequence of operations could be initiated by a crew console command, or could be 
activated automatically by a command or signal from a ground control station. The NOS 
thus provides the capabilities that allow local or remote users to access payload data, 
initiate or schedule activities, run programs, monitor status, and to use the facilities 
provided by the DMS. 

The NOS must also manage system functions within the DMS. This is a particularly 
important consideration for critical subsystems that utilize DMS processors, data base 
facilities, or communications links. For example, the health and status of the subsys- 
tems will be monitored by ground control, at least during the early stages of station 
operation. The data collected from onboard sensors such as temperature, pressure and 
attitude, will need to be formatted into messages and downlinked to ground sites. The 
processors and data communications interfaces and equipment needed are part of the 
DMS, and are controlled by the NOS. 

Many such functions are critical, in that equipment failures could result in loss of auto- 
mated control functions, or loss of ground control and communications. Computer and 
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electronic systems are subject to random failures, even though space-qualified devices 
may be utilized. For example, all known semiconductor devices are vulnerable to upsets 
or permanent damage from cosmic radiation, and computer memories are particularly 
sensitive. The only solution appears to be the provision of redundant equipment, with a 
capability for reconfiguration in the event of a failure. 

Reconfiguration of a large distributed system or LAN can potentially be accomplished 
automatically, but the impact on system performance may be unpredictable. At a mini- 
mum, the basic operational capabilities of the system should be maintained, even though 
certain payloads or instruments might have to be shut down. Automatic fault detection 
within the DMS may be accomplished by use of built-in test (BIT) logic and software 
diagnostics. However, selection of alternate processors or communications paths, and 
shutdown of noncritical equipment should be a function of the NOS, under the control of 
one or more executive processes running on the DMS computers. Development of an 
automated diagnostic and reconfiguration software system, as part of the NOS, appears 
to be a major task. So-called nonstop computer systems exist, but they are not in com- 
mon usage, and are not 100% effective. Considerably more research is needed if such a 
capability is to be available for use aboard the station. A key approach needed for such 
a technology development is the use of software simulation to model the DMS and the 
NOS, and to test the response of the system to the injection of simulated faults. 

3 A SUMMARY OF RESULTS 

This section focuses on the specific technologies identified in the study, that are neces- 
sary or beneficial in the data management area. They are discussed above, but this 
section highlights the key areas, with some discussion of the technical merits of each 
item. The discussion is broken into two main segments. First, the results of the tech- 
nical effort (task 1) are summarized. Second, the analyses of criticality, cost and 
program lead-time (task 2) will be discussed. This leads to the conclusion and recom- 
mendations in subsequent sections. 

3.4.1 Task 1 Results 

The technical effort was completed before the midterm review, and a total of sixteen 
candidate technology items were reported as worthy of development or extended study. 
The items were derived in part, by addressing the mission configuration analysis, the NIU 
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assessment, and the NOS subtask from three viewpoints: (1) what technologies are 
needed for DMS development; (2) what are those needed to provide a basic DMS opera- 
tional capability; and (3) what are those needed to provide DMS support to missions such 
as LOARS, CAMPS, and CADMS. For example, items 2 and 13 below would be needed to 
develop the DMS, while items 1 and 5 would be needed to support the LOARS mission. 
The breakdown is representative of an advanced DMS; however, the use of modularity 
would allow the system to be gradually built-up to this level of capability, with mission- 
specific technologies incorporated last. The configuration analysis subtask led to the 
identification of eight items, as follows: 

1. High-speed sensor data buffer. 

2. Payload development system. 

3. Maintenance expert system. 

Space-qualified disk or bubble memory. 

5. Onboard digital image processor. 

6. Interactive crew workstation. 

7. Adaptive digital control system. 

8. DMS simulation software package. 

The NIU description subtask resulted in the identification of five technology items or 
areas, as follows: 

9. Decoder-demodulator integrated circuit. 

10. Fiber-optic input/output interfaces. 

11. Standard NIU data buses (internal and external). 

12. Standardized microcomputer board set. 

13. Interface verification test set. 

The NOS definition subtask resulted in the identification of three software technology 
items for development, as follows: 

1*». Real-time NOS executives. 

15. Layered communications protocols. 

16. Distributed voting/diagnostic algorithm. 
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Task two resulted in some modifications to the priorities for each of the items or areas, 
based on program criticality, cost, and estimated lead time. These considerations are 
discussed in the next major section. The following paragraphs provide a brief description 
of the purpose or need for each item. 

3.4. 1.1 High-Speed Sensor Data Buffer 

The high-speed sensor data buffer is needed for data acquisition from radars, CCD tele- 
scopes, and other sensors that will have their signal outputs digitized. The data buffer is 
a semiconductor memory that can be loaded with considerable amounts of data at very 
high speeds. The data can later be read out of the buffer and stored in an archival 
memory or transmitted to the ground, at a much lower speed, whenever convenient. For 
example, 800 dynamic memory ICs, with a one-megabit capacity each, would provide 100 
million bytes of high-speed data storage. Such chips should be commercially available 
during the late 1 980s. 

3.4. 1.2 Payload Development System 

The payload development system would allow laboratories or contractors to develop 
flight hardware that is compatible with the onboard DMS, in a straightforward fashion. 
The development system would consist of a DMS compatible computer, a version of the 
NOS, and a NASA-approved high-order programming language package. 

3.4. 1.3 Maintenance Expert System 

The maintenance expert system is a software package that would be used to aid crew 
members in on-orbit repairs or scheduled maintenance. It would have a graphics output 
capability for display of technical diagrams, and would also have a set of troubleshooting 
rules or techniques programmed in to aid the crew members in fault isolation. Software 
diagnostics and BIT circuitry could also be included. 

3.4. 1.4 Space-Qualified Disk or Bubble Memory 

The space-qualified disk or bubble memory would provide online data storage for an on- 
board database. Currently, tape recorders are used in most space applications, but they 
provide very slow access to data, and are unsuitable for many database applications. 
Disks would provide the required speed, but reliability, rotational momentum, and uncer- 
tainties about head behavior in a microgravity environment might pose problems. 
Magnetic bubbles are a potential solution, but commercial availability may be low. 
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3.4.1 .5 Onboard Digital Image Processor 

An onboard digital image processor would have applications in the reduction or com- 
pression of data prior to storage or downlink. It could also be used in materials pro- 
cessing and life sciences laboratories for automated inspection of samples such as 
crystals or blood cells. 

3.4. 1.6 Interactive Crew Workstation 

The interactive crew workstation would allow convenient access to the DMS database, 
and would provide a means for system command and control. It might include color 
graphics capability and could also allow access to the maintenance expert system. 
Multiple workstations would be located in various station modules. 

3.4. 1.7 Adaptive Digital Control System 

An adaptive (or adaptable) digital control system would consist mainly of a set of stand- 
ard software routines that could be used for different control system applications aboard 
the station. It would provide support for sensor data acquisition through use of control 
processes running on DMS computers. The control programs would also monitor the 
status of subsystems or equipment and would issue commands to drive relays, pumps, or 
other actuators and effectors. The approach would tend to reduce software development 
costs by providing a common library of functions that could be used in many control 
applications. 

3.4. 1.8 DMS Simulation Software Package 

The DMS simulation software package is described in sections 3.5 and 3.6 and basically 
would allow detailed testing of the DMS network hardware and software before a 
commitment is made to a specific design approach. That is, software models of DMS 
devices, communications links and software processes could be evaluated or traded, 
before development. 

3.4. 1.9 Decoder-Demodulator Integrated Circuit 

A decoder-demodulator integrated circuit would reduce the complexity of high-perform- 
ance digital communications receivers, by replacing many discrete components in each 
receiver. This circuit is critical because it extracts data from an incoming modulated 
signal, and largely determines the achievable data rate (high) and error rate (low). 
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3.4.1.10 Fiber-Optic I/O Interfaces 

The fiber-optic I/O interfaces are the transmitters and receivers used in the NIUs to 
establish high-bandwidth digital baseband communications throughout the station. They 
include buffer memories, modulators and demodulators, optical sources and detectors 
and control circuitry. These interfaces plug into the NIU high-speed parallel bus. 

3.4.1.11 . Standard NIU Data Buses 

The standard NIU data buses are described in sections 3.3.1 and 3.3.2, and include the 
NIU internal high speed parallel bus, as well as the local serial buses within the station 
modules. The intermodule communications are handled by the fiber-optic I/O interfaces 
described above. The internal parallel bus connects standard CPU and interface boards 
within the NIU, as described in the next paragraph, while the local buses provide inter- 
facing points for the medium-speed devices (10-25 MBPS) within each module. 

3.4.1.12 Standardized Microcomputer Board Set 

The standardized microcomputer board set could take two forms. Many system inter- 
facing requirements could be satisfied by a set of common modules that plug into the 
NIUs. The other type would be used in payloads, instruments or other station equipment. 
The primary advantage in having a set of standard modules is the reduction in life cycle 
costs brought about by reduced logistics and maintenance difficulties. Customized 
circuit boards could be used where required, but duplication of functions would increase 
the number of spares that would have to be carried aboard the station and might cause 
supply problems over a period of many years. 

3.4.1.13 Interface Verification Test Set 

The interface verification test set would be used by station contractors to validate their 
equipment inhouse, before installation in the station modules. It would consist of stand- 
ard interface connectors, circuitry and software, plus diagnostic software to exercise the 
various attached devices. 

3.4.1.14 Real-Time NOS Executive 

The real-time NOS executive consists of the software processes that control the DMS. 
Each computer in the system would have an executive process running continuously to 
schedule tasks, control attached devices, and handle communications. 
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3.4.1.15 Layered Communications Protocols 

Layered communications protocols are the commonly accepted method for providing 
communications within a network. The lowest layers provide direct control of hardware. 
Successive layers are added to provide greater sophistication until the application layer 
is reached. The application layer gives users access to the network communications 
facilities. 

3.4.1.16 Distributed Voting/Diagnostic Algorithm 

The distributed voting/diagnostic algorithm would be used for automatic fault detection 
in the DMS. Box or module level redundancy would probably be used. For example, if 
box level redundancy is chosen for a functional area, critical processes would be 
executed on multiple processors with the results cross-checked by interprocessor 
communications. If at least three processors execute the same function and reach the 
same result, then the critical function can be initiated. If the results disagree, at least 
one of the processors must be in error and must be reset, tested, or shut down. 

Diagnostic routines could be run periodically, in the same way, to continuously test DMS 
health and status for either box level or module level redundancy. 

3.4.2 Task 2 Results 

In task 2 the goal was to evaluate each of the technology items or areas in terms of costs 
and benefits to the Space Station program. The specific approach taken in the DMS area 
was to estimate the time of need for the technologies, the required lead time, the devel- 
opment cost and risk, and the value or savings over the life of the station. Figure 3.4-1 
summarizes the need, lead, cost, risk, and value for each technology, and the following 
paragraphs discuss the rationale for that data. 

The 16 technology areas identified during task one were scored in five categories, with a 
rating of 0, 10, or 20. For example, a technology needed early in the program is more 
critical to success than one that is needed late, so a score of 20 would be assigned. The 
total scores give a rough estimate of the program criticality of each of the 16 tech- 
nologies. That is, an area with a high score is an area that has a likelihood of greater 
program impact. An area with a low score, such as the high-speed sensor data buffer, 
may still be important; however, low cost and risk, combined with a late need and rela- 
tively short lead time mean that the relative program impact is quite low. 
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3.4.2. 1 High-Speed Sensor Data Buffer 

The high-speed sensor data buffer will be needed after the station becomes operational 
to support imaging sensor payloads. It seems to pose no great difficulties in terms of 
lead time, cost, or risk, except for the possibility of data disruption by cosmic radiation. 
This type of sensor data is not flight critical, and the upset problem should be 
manageable if error detecting and correcting codes are used to preserve data integrity. 
The primary savings will be in the elimination of high-speed onboard recorders, and the 
related maintenance and replacement costs because semiconductor memories are very 
reliable compared to electromechanical devices. 

3.4.2.2 Payload Development System 

The payload development system is, by definition, required for development of payloads 
for various onboard applications and is therefore an early-need item. Choice of a 
processor, language, and a set of I/O interfaces for a wide variety of applications are the 
greatest difficulties. The main value is commonality and standardization, with savings in 
development cost due to reduction of duplicated effort at different facilities. 

3.4.2.3 Maintenance Expert System 

A maintenance expert system would be very useful to crew members in troubleshooting 
and scheduled maintenance. However, this is an emerging technology that will need 
considerable amounts of time and money for development. The value would be high 
because it could save one-half of a crew member's time, or more, but it is also a high- 
risk development item. 

3.4.2.4 Space-Qualified Disk or Bubble Memory 

This memory would support an onboard database, and would be used primarily for station 
operations, rather than for experiment data storage. The disk would be a development 
from existing technology and would involve high risk only if its rotational momentum 
caused unacceptable torques, or if the microgravity environment resulted in unpredic- 
table read/write head behavior. A magnetic bubble memory is a viable alternative, that 
involves no moving parts. It would not have mechanical problems and should be very 
reliable, but availability of space qualified bubble memory chips is in doubt. Therefore, 
this technology involves some risk, but seems essential for normal station operations. 
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3.4.2 .5 Onboard Digital Image Processor 

An onboard digital image processor would be an advancement from current technology. 
Such specialized processors are in use in medical imaging laboratories and at NASA 
facilities. With new (VHSIC/VLSI) technology, it should be possible to package and 
qualify such a processor for the station, but it would probably be quite expensive to 
develop because a considerable amount of software is also needed. The main value would 
be a reduction in the need for high-bandwidth imagery transmission to and from ground- 
based facilities because digital imagery could be enhanced or otherwise processed 
onboard. 

3.4.2.6 Interactive Crew Workstation 

An interactive crew workstation would be an advanced data entry and display console 
utilizing advanced microelectronics and software. Examples of advanced technologies 
are flat panel displays, high-resolution color graphics, multifunction keyboards, and 
expert systems. The workstation would be needed for normal operations and would have 
a high value because of potential increases in crew productivity. The risk would be 
relatively low if this is viewed as an evolutionary development. That is, only the 
essential capabilities would be implemented early in the program, with enhancements 
added later. 

3.4.2.7 Adaptive Digital Control System 

This technology would be needed for development of onboard control systems early in the 
program. That is, if a common library of control system software is to be of use, it will 
have to be available when the systems are implemented and tested. The risk is probably 
less than the risk of developing and integrating ten or more separate and independent 
control software packages, and the same rationale appears to apply in terms of life cycle 
cost reduction. Therefore, the value could be quite high. 

3.4.2.8 DMS Simulation Software Package 

If a simulation package is to be utilized in the early stages of DMS design, it will 
obviously have to be developed very soon. It could be used later in the program to help 
determine the impact of system modifications, but its primary value is in the early 
analysis and trade study phases when different system concepts must be evaluated. The 
DMS simulation software package has the highest priority of any of the technologies 
addressed in this study. The main risk is that the simulation runs might have poor 
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verisimilitude, that is, if a true representation of the DMS is not modeled accurately, the 
simulations may be useless or detrimental to station development. 

3.4.2. 9 Decoder-Demodulator Integrated Circuit 

This IC would be needed when the station becomes operational, but discrete logic 
circuits could be used to support DMS development. It would not be a tremendously 
complicated circuit because it would consist primarily of a phase-locked loop and a few 
shift registers. However, it might be difficult to achieve high data rates with current 
technology. The primary value would be a reduction in the complexity of onboard digital 
communications receivers, including those used for intermodule optical communications 
links. 

3.4.2.10 Fiber-Optic Input/Output Interfaces 

As with the decoder -demodulator IC, the optical I/O interfaces would be needed at the 
IOC point, but the remainder of the DMS could be developed using alternate means of 
digital communications. The space-qualified interfaces could be substituted before the 
station enters its operational phase. The main risk seems to be the potentially low 
reliability of the optical sources and detectors, and the fragility of the optical connec- 
tors. The primary values appear to be high bandwidth potential for video and high-speed 
sensor data distribution, and electrical isolation between equipment located in different 
space station modules. 

3.4.2.11 Standard NIU Data Buses (Internal and External) 

The primary advantages of bus standardization appear to be ease of systems integration, 
and reduced development and life-cycle costs due to equipment commonality. The NIU 
internal parallel bus, and the intra-space-station module serial buses will be needed 
during system development. They are an advancement from current technology, and 
seem to pose no great risks. However, once specified, they will probably have to serve 
as standards throughout the life of the station. Therefore, they should be evaluated and 
specified very carefully, to ensure that sufficient performance and growth potential are 
provided to serve station requirements over many years. The DMS simulation software 
package should be of considerable value in this analysis and specification process. 

3.4.2.12 Standardized Microcomputer Board Set 

A standardized set of circuit boards could be developed relatively easily, and would be of 
considerable use in various subsystems, instruments, and experiments. Most such appli- 
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cations will require a small amount of data processing capability for status monitoring, 
control, or data collection; and microcomputer technology is well suited for these roles. 

If standard boards are to be used, then early development is essential. The main values 
are reduced development and life-cycle costs, due to a reduction in duplicated hardware, 
reduced software development costs, and limitations in the variety of spares that must 
be procured and carried onboard the station. Early obsolescence is a potential disadvan- 
tage; however, if the boards are configured for a standard parallel bus, such as the NIU 
internal bus, then new versions can be introduced as technology developments warrant. 

3.4.2.13 Interface Verification Test Set 

An interface verification test set would be required early in the development program, 
to ensure that different contractors conform to DMS interfacing standards and communi- 
cations protocols. Lead time may be a problem because the standards and protocols 
must be developed first. Development of the test set should be relatively straight- 
forward from that point, especially if the standard board set can be utilized. The 
primary value is ease of systems integration over the life of the station. 

3.4.2.14 Real-Time NOS Executive 

The NOS executive modules provide all DMS control and operational functions and are 
needed early in the program to allow integration of equipment into the DMS. This area 
involves the greatest potential risk and cost in the software area because flight critical 
functions may be involved, as well as all DMS-user support capabilities. Efficiency, high 
performance and fault tolerance are crucial to program success. 

3.4.2.15 Layered Communications Protocols 

The DMS cannot function without communication protocols. They are needed for early 
systems integration and should remain constant over the life of the space station. Such 
protocols have been in use for several years (e.g., ARPANET) and do not require tech- 
nological breakthroughs for implementation. However, specification of the protocols 
will have significant implications in terms of reliability and efficiency of onboard and 
external communications. The protocols must be carefully analyzed and specified; this 
process will almost certainly require the DMS simulation package described above. 

3.4.2.16 Distributed Voting/Diagnostic Algorithm 

If the DMS is to have a fail-safe, fail-operational capability, then some means of auto- 
matic fault detection is clearly required, at least for critical functions. An algorithm 
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that uses multiple distributed modules or boxes to cross-check computational results is 
needed by the time the station enters its operational phase. The primary risk is that the 
algorithm may cause a considerable amount of processing overhead, or that it may 
operate unreliability. Its value is in the reduction of risk with respect to crew safety and 
mission success. 

3.5 CONCLUSIONS 

The work performed during this study led to conclusions in three main areas, involving 
data management system configurations, system hardware (NIU) and system software 
(NOS). Three potential mission configurations were analyzed, with the Land, Ocean, and 
Atmospheric Research Station (LOARS) model developed in enough detail for simulation 
studies to commence. The NIU was analyzed to the point where component technologies 
could be identified; and the NOS was defined to a level of detail that included identifi- 
cation of software functions and their functional interrelationships. These analyses 
were then used in the second part of the study, task 2, to help in the evaluation of the 
need for each technology in terms of program phase, plus estimates of relative cost, risk 
and value to the program. This work is summarized in figure 3.4-1. 

In the previous study, development of the NIU was estimated to cost $9.4M and the NOS 
development was estimated to cost $6.0M. The RCA PRICE computer model was used 
for these estimates, as described in volumes II and IV of the Advanced Platform Systems 
Technology Study. During the present study, a third estimate derived from in-house 
experience was made for development and use of a DMS software simulation package. 
Over a six-year period, leading to space-qualified hardware and software, development 
and use of the simulator is estimated at $6.85M, as described in volume III of this report: 
"Technology Advancement Program Plan." 

Incorporation of the simulator, the NIU and the NOS recommendations provide the great- 
est cost savings to the program. The total cost of development for the three items is 
$22.25M over six years. With estimated development cost savings to the program of 
$176M, primarily in reduced systems integration costs, the ratio of benefits (savings) to 
cost is 7.9. That is, for every dollar spent on network simulation, hardware (NIU) and 
software (NOS), NASA can expect savings in DMS development cost of almost eight 
dollars. The potential savings in operating costs are also considered to be quite signi- 
ficant, and are worth investigating in future studies. Space Station DMS development 
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involves critical paths. That is, some technologies are needed before others, and are in 
fact needed to facilitate their development. The most critical technology area appears 
to be computer-aided engineering (CAE), or computer simulation of networks and 
complex data systems. 

Simulation is an essential analysis tool for DMS development. If an adequate simulation 
capability is available, then logical models of system components can be developed and 
evaluated in different configurations with optimization as the primary goal. The station 
has many potential missions and operational requirements that must be fully evaluated 
before advanced development can begin. Hence, a DMS simulation system is the most 
valuable analysis tool that could be used in preliminary configuration studies. 

After the optimum system architecture has been defined, implementation can begin. 

This will likely involve development of engineering models first, with flight hardware to 
follow. This will require standardization of system hardware and software interfaces and 
communications protocols to facilitate systems integration. DMS system components 
and functions will be under the control of software executives that reside on DMS com- 
puters. Therefore, the processors, interfaces, buses, protocols, and executives will have 
to be specified and developed very early in the program, after simulation studies. Then, 
development of applications, payloads, experiments and subsystems can begin, insofar as 
the DMS is involved. That is, those areas that require DMS services can be developed 
independently up to a point until they reach the place on their critical paths where the 
DMS services are absolutely necessary. At that time, the DMS must be up and running, 
at least in a preliminary form, or Space Station developmental progress will be hampered 
at best, or halted at worst. 

3.6 RECOMMENDATIONS 

As a result of this study, it is recommended that DMS simulation capabilities be devel- 
oped first, so that potential mission configurations and the interactions between DMS 
hardware and software components can be fully analyzed in time to support space station 
full-scale development. 

The other technologies needed for DMS development have almost as high a priority as 
the simulator. Two such items were identified during this study, as follows: 


70 



D180-27935-2 


a. Interface verification test set. 

b. Payload development system. 

The test set would be of great benefit to contractors, and the development system would 
be useful to experimenters or entrepreneurs who wish to develop DMS-compatible pay- 
loads. Of the remainder of the sixteen technology items, none could be eliminated as a 
result of this study. They are ail needed to enter the space station full-scale develop- 
ment phase, but are of a less urgent nature. Simulation is the most urgent technology 
item, and because of its early use in space station development, it is discussed in more 
detail with second tier recommendations. 

Simulation of large data systems is a computer-aided engineering (CAE) technique that 
can greatly reduce development costs, while increasing system effectiveness. Almost by 
definition, large systems and networks are extremely complicated and are usually quite 
costly. Before committing large sums to the design of such a system, a model should be 
developed using simulation software package to give an early indication of system 
behavior in realistic scenarios and to allow a degree of optimization prior to actual 
development. 

Selection of the final DMS architecture from the results of this study would be prema- 
ture but progress has been made in the development of tools to support that decision. 
Also, of the three mission models considered in the first part of the study, the Land, 
Ocean, and Atmospheric Research Station (LOARS) model has been developed in enough 
detail to allow initial modeling and simulation activities to begin as an internal R&D 
project supported by BAC. 

As mentioned above, one of the purposes of this effort is to determine how fault-toler- 
ance can be implemented in the DMS. Figure 3.6-1 shows how the simulation could be 
used to inject errors and hard faults into the model, to determine the impact on system 
functionality, and to test the performance of automatic reconfiguration algorithms. The 
simulation consists of several software modules, as shown in the diagram. The most 
important are the packet producers, servers, consumers, and the instrumentation module. 
Producers simulate the production of messages or packets that, in a real system, would 
be transmitted by the devices that make up the DMS. The servers simulate the behavior 
of the network communications components and software protocols. Consumers are the 
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Figure 3.6-1 DMS Closed Loop Simulation 
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devices to which the messages or packets are sent. And finally, the instrumentation 
module performs data collection and simulated fault injection. 

When fully devloped, the simulation package would allow the user to design a network 
interactively, using a color graphics terminal. Models of the devices attached to the 
network are entered into the system database, and graphical representations will be 
displayed on the color monitor, including the network interconnections. The simulation 
output consists of statistical measurements acquired by the instrumentation module, 
displayed graphically as letters, numbers and colors. For example, the symbol for a 
failed device could be displayed in red, and the utilization of a communications link 
displayed as a numerical percentage. 

Simulation allows the use of modern CAE techniques in DMS design, in the same way 
that integrated circuits are designed and simulated prior to fabrication, and for the same 
reasons. Simulation can give an excellent indication of system performance before 
major resources are committed to production and various concepts can be traded and 
compared to produce an optimal design. 
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4.0 LONG-LIFE THERMAL MANAGEMENT 


4.1 INTRODUCTION 

The objective of the present long-life thermal management study was to identify heat 
transport system technologies that increase performance, enhance system life, and 
reduce system weight and cost. Emphasis was placed on two-phase heat transport sys- 
tems that may offer significant performance benefits. These systems absorb and reject 
heat at a near constant temperature. This isothermal characteristic simplifies thermal 
interfaces and allows heat loads to be placed at any available location thereby providing 
a high degree of flexibility in reconfiguring the space station. Reduced pump power 
requirements and heat transport by latent heat of vaporization provide size and weight 
reductions compared to a conventional pumped liquid-loop heat transport system. These 
comparisons made possible the identification of new technology areas requiring advance- 
ment. 

The two technology areas identified were— 

1. Two-phase water thermal transport loops for inhabited environments. 

2. Pumps and heat exchangers for liquids in the nearly-saturated state in zero gravity. 

The study approach, technical discussion of study, results, conclusions, and recommenda- 
tions are presented in the following sections. 

4.2 APPROACH 

The overall study was divided into three tasks outlined below: 

Task 1 

1. Define baseline pumped two-phase heat transport system. 

2. Optimize baseline system. 

3. Identify optional systems. 

a. Pumped liquid loop. 

b. Capillary two-phase. 

c. Alternate two-phase pumping concepts. 
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Task 2 

1. Compare baseline and optional systems. 

2. Select technologies for advancement. 

Task 3 

1. Develop technology implementation plan. 

This section of the report describes the task 1 and task 2 efforts. 

The study groundrules are described in section 4.3.1, and the basic heat transport 
systems are defined in section 4.3.2. The detailed technical discussion for system 
optimization and comparison is covered in sections 4.3.3-4.3.8. The summary of results, 
conclusion, and recommendations are presented in sections 4.4, 4.5, and 4.6, 
respectively. 

Detailed analyses were performed for pumped two-phase, capillary two-phase, and 
pumped liquid-loop systems. These systems share common elements (pipes, radiators, 
heat exchangers) and each must be optimized to provide a valid comparison. Conse- 
quently, the technical discussion is based primarily on system elements rather than on a 
task 1 and task 2 division. 

4.3 TECHNICAL DISCUSSION 

4.3.1 Groundrules for Study 

The following basic groundrules were established for the study: 

1. Platform total heat load: 25-150 kW. 

2. Transport distance: approximately 150 ft one way. 

3. Grumman Space Constructable Radiator 1.2 lb/ft^. 

4. Power penalty: 350 lb/kW. 

5. Heat transport fluids: 

a. Two-phase: ammonia. 

b. Pumped liquid: Freon 1 1, Freon 1 14, ammonia. 

6. Low temperature (about 40°F) heat rejection for metabolic and battery heat loads. 

7. High temperature (about 80°F) heat rejection for remaining loads. 

8. Radiation sink temperature: 415°R. 
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9. Pumped water heat transport loop inside pressurized modules. 

10. Elements for each system: 

a. Radiator. 

b. Cold plates. 

c. Pressurized module interfaces. 

d. Transport loop. 

11. Thermal storage interface inclusion is beyond scope of study. 

During the course of the study results showed that there were only minor differences 
between Freon 11 and Freon 114. Consequently, the detailed analyses were completed 
for Freon 11 only. It also became apparent that a two-phase water heat transport 
system inside the pressurized modules offered benefits and was added to the study. 

The groundrules listed here were augmented by a baseline space station definition (sec. 
4. 3. 7.1). This further definition was required for the heat transport system comparison 
on an overall system basis. 


4.3.2 Heat Transport Systems 

Figure 4.3-1 shows the basic heat transport systems that were analyzed in this study. 

The baseline is a pumped two-phase system with a liquid and vapor lines. A mechanical 
pump is used to pump the liquid condensate from the radiator to the heat source heat 
exchangers (evaporators). Control vaiverizing a two-phase heat transport systems within 
the long life requirement constraints. Each of these approaches produced useful 
advancements in the understanding of technology issues and development needs. 

The overall study was divided into four tasks. During task 1 the design concepts required 
in each of the four study areas were refined and comparative studies were conducted. 

The pumped liquid loop is similar to the baseline system except that the heat is 
transported as sensible heat rather than as latent heat of vaporization. 

Alternate pumping concepts were briefly considered for the baseline pumped two-phase 
system. One concept would use an osmotic pump in the liquid line. The liquid would 
consist of a solvent and solution separated by a semipermeable membrane. The osmotic 
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pressure across this membrane causes solvent flow through the membrane into the solu- 
tion. The solvent evaporates from the solution at the evaporators, condenses in the 
radiator, and returns to the membrane. The other concept considered uses an io/i drag 
pump. This pump uses a high voltage probe to generate and accelerate ions in the fluid. 
These ions exchange momentum with the fluid and produce the pumping action. 


4.3.3 Heat Transport Loop Sizing 


4.3.3. 1 Pumped Two- Phase Transport Loop 

The pumped two-phase loop consists of a pumped liquid supply line to the evaporators 
and a vapor return line to the radiator. The weight of the loop includes line weight, fluid 
weight, and pump power penalty. For turbulent flow (cases of interest are in turbulent 
flow regime) and small wall thickness compared to line diameter, the weight per unit 
length of line (vapor or liquid) is given by 

, <it 9 . V . . M 0*25, o 2 * 75 

Wt/l .1, P D tD . | p d2 <■ F ( -L) ( p f -- 2 : 7 - j) ^ 



density of line material (aluminum in present study) 

wall thickness 

inside diameter 

fluid density 

fluid viscosity 

latent heat of vaporization 

heat load 

power penalty 

pump efficiency 


The factor F includes a factor to account for additional pressure losses due bends, 
valves, etc. (assumed to be 25% in this study) and a factor to account for the load 
distribution along the line. Two load distribution cases were considered. The most 
severe case is that of the load being concentrated at the opposite end of the loop from 
the radiator. In this case F = 1.25. The other case is that of a uniform load distribution 
along the loop where F = 1.25/2.75. 
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The assumed minimum wail thickness is 0.03 inches and is increased as necessary to keep 
the wall stress below 5000 psi (based on fluid vapor pressure at 125°F). For the 
increased wall thickness cases, t is proportional to D and an analytical expression can be 
found for the optimum diameter that minimized the weight per unit length. Otherwise, 
the optimum diameter must be determined iteratively. 

Two-phase ammonia heat transport loops were optimally sized as a function of heat load 
for high (86°F) and low (32° F) temperature systems. The line sizing, pressure drop and 
pumping power, and weight per unit length are shown in figures 4.3-2, 4.3-3, and 4.3-4, 
respectively. 

For the pumped two-phase transport loop the optimization is essentially independent of 
other system component (e.g., radiator) optimizations. The vapor line pressure drop will 
provide a coupling of the transport loop optimization to other system component optimi- 
zations since this gives rise to a difference in evaporation and condensation tempera- 
tures (i.e., an additional temperature drop between heat source and radiator). This 
temperature difference, however, is insignificant for the two-phase ammonia systems 
considered in this study. 

4.3.3.2 Capillary Two -Phase Transport Loop 

The capillary two-phase loop is similar to the pumped two-phase system except that the 
pumping action is provided by surface tension. The loop weight consists only of line and 
fluid weight. The weight per unit length (of total transport distance) is 

Wt/1 =|p 0 [(tD) v + (tD)jJ +| [(pD 2 ) v +(pD 2 )J 
where subscript v refers to vapor and 1 refers to liquid. 


The vapor and liquid line sizes are constrained by the surface tension pumping capacity 
per total (previously, a detailed analyses of the thermal storage interface was beyond the 
scope of the study.) 

The capillary two-phase system is similar to the baseline system, except pumps arid 
valves are not required. The capillary wicks in the heat exchangers provide the required 
transport length. 
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Figure 4.3-2 Pumped Two-Phase Bus Sizing 
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Figure 4.3-3 Optimized Pumped Two-Phase Ammonia Bus Pressure Drop and Pumping Power 
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Figure 4.3-4 Pumped Two-Phase Bus Weight for Optimized Liquid and Vapor Line Sizes 
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h w/l 


FQ 

P^hfg 


1.75 

TJT 


, P 0.25 x , \1 0.2 5 n 

* pD^75 ;v + l p D 4.75'l 


where 

h w = wicking height capacity (i-g) 
g = acceleration of gravity (1-g) 

For a given wicking height to transport length and heat load these equations can be used 
to determine optimum vapor and liquid line diameters that minimize the transport loop 
weight. The weight and line sizing for an optimized capillary two-phase transport loop is 
shown in figure 4.3-5 for the high temperature bus and figure 4.3-6 for the low tempera- 
ture bus. Also shown are reference points for a 300-ft transport distance with a 100 kW 
high temperature load and a 25 kW low temperature load. The reference points assume a 
wicking height capability of 1 inch under normal gravity. This corresponds to a wick 
pore diameter of 0.020 inches for the high temperature case and 0.025 inches for the low 
temperature case. 


4.3. 3. 3 Pumped Liquid Transport Loop 

The pumped liquid transport loop sizing is similar to that for the pumped two-phase case 
except the flow rate is an independent variable. In this study the flow rate variation is 
implicit in the fluid temperature change. The weight per unit transport length is given 
by 


ml1 - PotD PD* . F(X-) (gf) 2 - 75 

where 

Cp = specific heat of fluid 
AT = fluid temperature change 

For a given heat load to temperature change ratio, this equation can be solved iter- 
atively to determine the optimum diameter that minimizes the weight. Figure 4.3-7 
shows the optimized pumped liquid transport loop weight for Freon 11, Freon 114, and 
ammonia. The transport loop'optimization is coupled to the optimization of other 
system components through its dependence on fluid temperature change. 
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Figure 4.3-5 Optimized Capillary Two-Phase Heat Transport Loop ( Ammonia ) 
f High Temperature Bus ** 869 F) 


84 





LINE DIAMETER ~ INCHES WEIGHT ~ LBS/FT 


D180-27935-2 




IQ- 6 F i a 1 * 75 /h w ~ FT-KW 175 /INCH 


Figure 4.3-6 Optimized Capillary Two-Phase Heat Transport Loop (Ammonia) 
(Low Temperature Bus ~ 32° F) 
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Figure 4.3-7 Pumped Liquid Loop Weight for Optimized Line Size 
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4.3.4 Heat Exchanger Models 

The system heat exchanger weights are a major factor in system optimization and con- 
sequently in comparing different systems. Figure 4.3-8 shows the heat exchanger models 
used for this study. A discussion of these models is presented in the following sections. 

4.3.4. 1 Two-Phase Heat Exchanger 

The two-phase heat exchanger model was based on the Grumman prototype design shown 
in figure 4.3-8 and no optimization of the design was attempted. The heat exchanger 
core weight, assuming a channel height of 0.2 inches (Grumman's design appears to have 
a total thickness of 0.2 inches) and equal volumes of metal and liquid in the liquid 
channel/support structure region, as 

Wt c = WL (Py/75 +Pj/600 +p o /600) lb 

W = heat exchanger width - ft 
L = heat exchanger length - ft 
P = density lbs /ft 3 

subscripts v, 1, o refer to vapor, liquid, and metal, respectively. 

The core weight was used for comparison with liquid heat exchangers where the opti- 
mized core weight is used (sec. 4.3.4.2). The cover sheet weight was included (for both 
two-phase and liquid systems) in the radiator panel heat exchangers (sec. 4.3.5) where 
the length and width are fixed values. 

The heat transfer coefficient to thermal conductivity ratio was taken as 6000 (ft)"*. 
(This corresponds to a Nusselt number of 5 and a characteristic dimension of 0.01 inches 
which is typical of heat pipe evaporators.) Due to the liquid channels the effective heat 
transfer coefficient for the heat exchanger is reduced to 80% of this value. Using this 
effective heat transfer coefficient the heat exchanger core weight can be related to the 
heat transfer rate and temperature difference, for example, 

Wt c = P ? * 8 ( P j + P n ) q 

105.4 k ( £j) lb 
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LIQUID LOOP 
HEAT EXCHANGER 




DIMENSIONS 
SELECTED TO OPTIMIZE 
SYSTEM 


TWO-PHASE BUS 
CONDENSER/EVAPORATOR 




SUPPORT STRUCTURE 
GRUMMAN PROTOTYPE DESIGN 


Figure 4.3-8 Heat Exchanger Models 
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where 

k = liquid thermal conductivity (BTU/ft-hr-°F) 

Q = heat transfer rate across one face of heat exchanger (kW) 

AT = temperature difference between vapor and heat exchanger face (°F) 

4.3.4.2 Single -Phase (Liquid) Heat Exchanger 

The single-phase heat exchanger model (shown in figure 4.3-8) requires a detailed analy 
ses to optimize the design parameters (a, b, and c). The core weight includes the metal 
liquid, and pumping power penalty. For cases of interest the flow through the heat 
exchanger is laminar and the core weight is given by 

Wt c = cLWp 0 ( ^ / f° f b/a & ) + “^3 (i + b / a > + c / a > 2 m2 

where m = mass flow rate 


For given b/a and c/a ratios the optimum c dimension for minimum weight is 

I ,"Y . .2411 (1 + b/aK (1 +c/aM * 

c 


/Y \ /24U (1 + b/a)2 (1 + c/a)^ ,m\2 

{ w ] ( p? p 0 (p/p 0+ b/ a r- ( w> 


Noting that at the optimum c value, the material weight is three times the power pen- 
alty weight 


Wt c = 4/3 c LWP 0 ( 


P/p 0 + b/a 
1+ b/a 


) 


where c is the optimum value. 


The effective heat transfer coefficient can be shown to be 

. , . tanhq 1 . 

i_ 1 + (c/a) ~~S (L±Sd± \ L'M, i 

heff = 1 + b/a K 2c ; KINU 


where Nu = Nusselt number (taken as 5 in this study) 


(c/aXl + c/a) /k ^ Nu 

° = (E755 — i<7 V 

k 0 = thermal conductivity of metal 
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a> 


a for one side only heat transfer 
2 a for two side heat transfer 


The effective conductance to weight ratio is (using the optimum c value) 


h effA 

Wt 


= §kNuP-< 



where 

5 = 

A = 


1 + (c/a) 

(1 + b/a)(p/p Q 

LW 


tanha' 


+ b/a)^ 


For a given c/a ratio, the optimum b/a ratio can be found that maximizes £ , and thus 
minimizes the heat exchanger weight to effective conductance ratio. 

As the c/a ratio increases the heat exchanger weight to effective conductance ratio 
asymptotically approaches a minimum value. For c/a large with respect to unity 



and the optimum b/a is independent of c/a as is the heat exchanger weight to effective 
conductance ratio. This approximation was used for all liquid heat exchangers except for 
those coupled to the radiator panels where, due to the coupling with other conductances, 
an optimum value of c/a exists (sec. 4. 3.5.2). 

The heat exchanger core weight can be written as 


Wt, 


= (ts«A> §r 

V 


where Q = heat transfer rate 

♦ = |wcpkNu (£-)(^L)^ 


max 


90 



D180-27935-2 


The liquid heat exchanger weight depends on the wall boundary condition. For a uniform 
heat flux boundary condition 

h eff A = at” 

A = heat transfer area v 

AT W = temperature difference between wall and fluid (constant for constant 
Nusselt number) 

The heat exchanger weight for this case is then 

- n (Q_)2 (AX,. ) 

Wt C " 0 'AT ^AT w ; 

where 

0 = 1 /ip for one side heat transfer 

= 1/2 for two side heat transfer 

This boundary condition case was used for cold plate heat exchangers and balanced coun- 
terflow heat exchangers. 

For a uniform wall temperature case 

h eff As *§t Ind + 5T^) 

where, in this case, 

AT W = smallest temperature difference between wall and fluid 
The heat exchanger weight for this case is then 
W, c = e <-g- T > 2 m (1^1 

This boundary condition case was used for liquid loop heat exchangers interfacing with a 
two-phase heat exchanger. 
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ft. 3. 5 Radiator Sizing 

The Grumman space constructable radiator was used as the radiator model for both two- 
phase and pumped liquid-loop heat transport systems analyses. This radiator model is 
shown in figure ft.3-9. Heat pipe radiator panels are clamped together with a heat 
exchanger unit sandwiched between them. The required radiator area is provided by 
placing the required number of radiator panel/heat exchanger units adjacent to each 
other. The radiator panel properties (size, weight, emissivity, fin effectiveness, panel, 
and contact thermal conductances) are based on Grumman's design values. The environ- 
mental radiation sink temperature was set at ftl5°R for the present study. This value is 
representative of a steerable radiator in low earth orbit with a completely degraded ( s 
= € ) thermal coating. 


ft.3.5.1 Two-Phase System Radiator 

The two-phase bus/radiator panel interface heat exchanger used for the radiator analyses 
is described in section ft.3.ft.l. The thermal balance for one heat exchanger unit coupled 
with two radiator panels is 

Q = 2K(T B - T r ) = 2 C'0nA(T R * - T S 4 ) 



K F = 
K C = 


Kr = 

e = 
n = 

A = 

t b = 

Tr = 
T S = 


heat rejection rate 

Thermal conductance from vapor to one radiator panel 
1 

L +L +L 

K F K C K 12 

vapor to heat exchanger for conductance 

contact conductance between heat exchanger face and radiator panel (1167 
BTU/HR-°F) 

radiator panel conductance (1000 BTU/HR °F) 

panel emissivity (0.8) 

fin effectiveness (0.58) 

panel area (100 ft^) 

two-phase bus temperature 

radiator fin root temperature 

sink temperature (ftl5o R ) 
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HEAT REJECTION RATE PER PANEL (BTU/HR) 
O- (T w - T w ) - (T w - Tp) - K R (Tp • T ft ) - 

nloi 

A -100 FT 2 

T s - SINK TEMPERATURE <°R) 


THERMAL MODEL (ONE-HALF OF SYMMETRICAL MODEL) 


CONTACT 
CONDUCTANCE 
(600 BTU/FT 2 -HR-°F) 
K^- 1167 BTU/HR °F 
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CONDUCTANCE 
K„ - 1000 BTU/HR-°F 


HEAT 

EXCHANGER 


NOTE: INTERFACE BASED ON GRUMMAN SPACE 

CONSTRUCT ABLE RADIATOR (NASA JSC 
CONTRACT NAS9-1S965) 


Figure 4JZ-9 Heat Transport Loop/Radiator interface 
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The vapor to heat exchanger conductance Kp for ammonia is 3200 BTU/HR-°F. This 
gives an overall conductance K of 461 BTU/HR-°F. 

For a given bus temperature Tjj an iterative solution to the thermal balance provides the 
heat rejection rate per radiator panels/heat exchanger unit. The radiator system weight 
required to reject this heat load consists of heat exchanger and radiator panels weight. 
The heat exchanger weight for ammonia as a working fluid and aluminum as the metal is, 
including 0.05-inch face sheets, 4.2 lb. The weight of the two radiator panels (1.2 lb/ft^) 
is 120 lb. The radiator system weight per unit heat rejection rate is the total weight 
(124.2 lb) divided by the heat rejection rate Q found from the thermal balance equation. 
Figure 4.3-10 shows the resulting radiator system weight as a function of two-phase bus 
temperature. 

4.3. 5. 2 Pumped Liquid Loop System Radiator 

The pumped liquid loop/radiator panel interface heat exchanger model is described in 
section 4.3.4.2. The thermal balance for one heat exchanger unit coupled to two radiator 
panels is (similar to two-phase system). 


Q = 2K (T in - T r ) = 2 ean.A(T R 4 - T S *0 

V . 

where Tj n is the fluid inlet temperature to the heat exchanger unit and the overall 
thermal conductance is defined as previously with the fluid conductance Kp now 
given by 


Kp = ^^2 (1 


_ e -2hpff Ar \ 

mCp 


m = mass flow rate through unit 
Ac = contact area (2.33 ft^) 


The radiator system weight includes, as before, the radiator panels and heat exchanger 
weight. The heat exchanger weight consists of cover sheets (identical to two-phase anal- 
ysis) and core weight as described in section 4.3. 4.2. The liquid loop system radiator 
analyses is more complicated than that for the two-phase system because the mass flow 
rate through the radiator panel heat exchanger units depends on the flow routing and the 
overall fluid temperature change. An additional complication is the weight optimization 
for each flow condition. 
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The pumped liquid-loop system radiator optimization was performed as follows. 

1. Select heat rejection rate for a set of radiator /heat exchanger units connected in 
series flow. This fixes the relationship between mass flow rate and fluid tempera- 
ture change for a given fluid. 

2. Select a fluid inlet temperature to the radiator system. 

3. Select the overall fluid temperature change through the set of radiators. 

4. For a given heat exchanger c/a ratio determine the optimum b/a ratio (iterative 
procedure) and calculate the fluid conductance Kp and heat exchanger weight. 

5. Determine number of radiator panels/heat exchanger units required to reject the 
specified heat load. This is accomplished by iteratively solving the thermal bal- 
ance equation for each unit. The radiator system fluid inlet temperature is used as 
the inlet temperature to the first unit and the first unit’s outlet temperature is 
used as the inlet for the second unit, etc. When the total temperature change 
exceeds the specified value, the final unit is prorated (i.e., fraction of a unit) to 
provide the specified temperature change. 

6. Calculate radiator system weight by multiplying the required number of units times 
the weight per unit. 

7. Determine minimum radiator system weight by incrementing heat exchanger c/a 
value (using an appropriate algorithm) and iterating (from step d.) until the opti- 
mum c/a is found. 

8. Select new overall fluid temperature change and repeat calculation (from step c.) 
to determine the minimum weight for this condition. An iterative procedure could 
be used here to find the optimum temperature change for the radiator system. 
However, because the fluid temperature change affects the weight of other system 
components, the optimum change must be based on the overall system optimiza- 
tion. 
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9. Select a new inlet fluid temperature and repeat calculations from step b. The 
radiator system weight decreases monotonically with increased inlet temperature. 
The absolute maximum inlet temperature is limited by the allowable equipment 
temperature and the optimum value must be determined on an overall system 
weight basis. 

10. Select a new heat rejection rate for a set of radiator /heat exchanger units and 
repeat calculation from step a. This would allow the optimum flow routing to be 
determined for various conditions. 

A limited investigation of the effects of flow routing showed the radiator weight per unit 
heat rejection rate to be insensitive to specified heat rejection per set of radiation 
panel/heat exchanger units over a wide range of values. Consequently, a convenient (and 
near optimal) value of 25 kW per set of series connected units was chosen for this study. 

The pumped liquid loop system radiator optimization provides the minimum radiator 
system weight as a function of radiator inlet temperature and overall fluid temperature 
change. Figure 4.3-11 shows an example of optimum radiator system weight for an inlet 
temperature of 70°F. As noted previously, the optimum inlet and outlet temperatures 
must be determined from an overall system optimization. 

4.3.6 Pressurized Module Pumped Water Loop 

The manned (pressurized) modules of the space station have a pumped water heat trans- 
port loop that transports waste heat to the main heat transport system by means of an 
interface heat exchanger. In order to compare two-phase and pumped liquid main trans- 
port systems, these internal water loops and associated heat exchangers must be included 
in the system analyses. 

4.3.6. 1 Two-Phase Main Heat Transport System 

Figure 4.3-12 shows the model used to analyze the water transport loop coupled to a 
two-phase bus. The water loop is coupled to the two-phase bus by means of an interface 
heat exchanger. One side of this heat exchanger is a two-phase heat exchanger (sec. 
4.3.4. 1) and the other side is a liquid heat exchanger (sec. 4.3. 4.2). These heat exchang- 
ers are assumed to be in intimate contact (or an integram unit) so that there is no tem- 
perature drop across the interface itself. The heat load to the water loop is applied 
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Figure 4.3- 1 1 Radiator System Weight for Liquid Loop Heat Transport System 
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Figure AJ3-12 Two-Phase Bus/Water Loop Interface 
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through a cold plate heat exchanger unit. The weight of the pressurized module loop 
consists of the pumped water loop itself (lines, water, pump power penalty) and the heat 
exchanger units. 


The water loop itself can be optimized as a function of heat load to water temperature 
change as outlined in section 4. 3.3.3. The heat exchangers can be optimized, as a set, in 
terms of heat load, water temperature change, and equipment to bus temperature differ- 
ence. The total weight of the heat exchangers is (see sec. 4.3.4) 


WtHX " ( t 6 ?t b ) U-4 Xi ln (1 " + ’? ( ‘tVTb ) ? 

Q = heat load 

T e = equipment temperature 

T B = bus temperature 


c = 

e = 

T = 


Py + (P| + P n/%) 

105.4k 


(see sec. 4.3.4.1) 


constant for liquid heat exchanger (see sec. 4.3.4.2) 
AT 

T e -T B 


AT = 

4 = 


water temperature change 

XeilH 

T e -T B 


Th = hottest water temperature 

c = Jh-Tw 

t h~ t b 

T v/ = Interface temperature (i.e., two-phase heat exchanger wall temperature) 


The temperature ratio variables (£ ,and T ) can be optimized to give a minimum total 
heat exchanger weight for a given heat load, bus, and equipment temperatures. For 
these given conditions, the weight of the water loop is based on the water temperature 
difference corresponding to the optimized value for the heat exchangers. A more 
refined analysis would include the water loop weight in the optimization of . The over- 
all effect of this refinement, however, is expected to be small. 


4. 3.6.2 Pumped Liquid-Loop Heat Transport System 

There are two cases to consider for the pumped liquid-loop heat transport system inter- 
face with the pressurized modules. One case is that in which there are separate heat 
transport systems for the high- and low-temperature heat loads. The other case is where 
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the same loop is used for both high and low temperature loads. The models for these 
cases are shown in figure 4.3-13. 

The analysis of the separate loop case is similar to that for the two-phase system 
described in the previous section. In this case, the interface heat exchanger is a bal- 
anced counterflow device and the optimized set of heat exchangers weight can be writ- 
ten analytically as 

W, HX * <gr> ( T^rr n > * 2e w^ 2 


where Tj n = radiator inlet temperature and subscripts m and w refer to the main 
loop and water heat exchangers, respectively. 


The total heat exchanger weight for the single-loop system includes that of the humidity 
control heat exchanger in addition to that of equipment cold plate and interface heat 
exchangers. The total heat exchanger weight for this case is 

w tHX 4<^ a&r 52 - 


+ °w (Qhp./Q) 

<MQe/Q) - ) 

1 e " 1 in 


AT = 
Q = 
Q e = 

Qhc 
t hc 
4> = 


AT 

Te"Tin 

water temperature change 
total heat load 
equipment heat load 
= humidity control heat load 

= humidity control temperature 

TeilH 

T e -T B 


For given Q e , Q HC , Tg> 

Thc> ^in 30 optimum $ value can be found that minimizes 
the weight at a given value of the parameter T . The range of values for this parameter 
is restricted by the constraints that the main loop liquid entering the interface heat 
exchanger must be above the freezing point of water and the water temperature leaving 
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Figure 4.3-13 Pumped Liquid Loop/Water Loop Interface 
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the humidity control unit must be less than the humidity control temperature. These 
limits are 


(S_) (XinzlHC) 
*Qe ^ ‘ e -T in } 


< T< 


Tin-32°F 

Te"Tin 


For given equipment specifications (Q e , QhC» T e , Thc)> the total pressurized module 
water loop weight (heat exchangers plus loop itself) depends on the radiator inlet tem- 
perature Ti n and water temperature change. The optimum value of these parameters 
must be based on total system weight considerations. 


4.3.7 Space Station Thermal Control System Sizing 


4.3.7.1 System Definition 

In order to compare space station heat transport systems a baseline space station must 
be defined. The following space station parameters were used as a baseline for compari- 
son: 

1. Total heat load: 125 kW. 

2. Round trip heat transport distance: 300 ft. 

3. Radiation sink temperature: -45° F (415°R). 

4. Equipment temperature: 85°F. 

5. Battery and humidity control temperature: 40°F. 

6. Heat load distribution: 

a. Equipment (85°F) 100 kW. 

(1) five unpressurized 10 kW cold plates. 

(2) five pressurized module 10 kW cold plates. 

b. Battery (40°F) 20 kW. 

(1) two unpressurized 10 kW cold plates. 

c. Humidity control (40°F) 5 kW. 

(1) five pressurized module 1 kW units. 

d. Load distribution along loop assumed to be midway between uniform and 
concentrated distribution cases. 

e. Separate high and low temperature two-phase heat rejection systems. 

f. Capillary system wicking height of 1 inch under normal gravity (1— g). 

g. Single pumped liquid loop system (battery cold plate in series flow down- 
stream of radiator in order to maintain a high radiator inlet temperature and 
that allows a reduction of radiator area). 
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h. Water heat transport loop inside pressurized modules. 

i. Materials: aluminum for main transport loop and stainless steel for water 
loop. 

j. Main transport fluid: ammonia for two-phase systems and Freon 11 or am- 
monia for pumped liquid loop systems. 

The heat load and transport distance are representative of a relatively mature space 
station. The baseline system assumes use of solar panels with battery storage. (A sys- 
tem utilizing fuel cells would require consideration of a higher temperature heat source.) 
Separate high and low temperature two-phase systems are used to minimize total system 
weight. The pumped liquid loop systems have the entire flow from the radiator pass 
through the battery cold plates before passing through any other heat exchangers. This 
constraint, on battery placement and flow routing, allows the radiator inlet temperature 
to be maintained at a high level, which minimizes the radiator size and weight. The 
pumped liquid loop is representative of current state of the art and the pumped liquid 
ammonia loop system allows direct comparison with the two-phase ammonia systems. 

4.3.7.2 Two-Phase System Optimization 

The two-phase bus (pumped and capillary), equipment cold plates, pressurized module 
heat exchangers and water loop, and radiator weights were calculated for the baseline 
space station at various bus temperatures. (The details of these calculations were de- 
scribed in the previous sections.) Figure 4.3-14 shows the high temperature system ele- 
ments and total weight as a function of bus temperature. The pumped and capillary two- 
phase systems are identical except for the bus weight itself. The minimum weight for 
both systems occurs at a bus temperature of about 70°F. Detailed sizes, weights, and 
temperatures are shown in the high temperature system schematic (fig. 4.3-15). 

The low temperature system element weights are shown in figure 4.3-16 as a function of 
bus temperature. The minimum total system weight occurs at a bus temperature of 
about 36°F. A detailed schematic for this optimum low temperature system is shown in 
figure 4.3-17. 

4.3.7.3 Pumped Liquid-Loop System Optimization 

For the given baseline space station conditions the pumped liquid loop systems have an 
optimum liquid temperature change that minimizes the system weight at a given inlet 
temperature to the radiator. Figure 4.3-18 shows the pumped Freon system element 
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Figure 4.3-14 High Temperature Two-Phase Ammonia System 
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VAPOR 

LINE 


PUMPED SYSTEM 
1J32 INCH ID 
0j056 INCH WALL 
150 FT LENGTH 
60 LBS 
0.28 PSID 
73 WATTS * 


CAPILLARY SYSTEM 
3.47 INCH ID 
0.107 WALL 
150 FT LENGTH 
218 LBS 



PUMPED SYSTEM 
0.496 INCH ID 
0JD30 INCH WALL 
150 FT LENGTH 
16.3 LBS 
3.64 PSID 
14.7 WATTS 


CAPILLARY SYSTEM 
1.77 INCH ID 
0J054 INCH WALL 
151 LBS 


TOTAL 


PUMPED CAPILLARY 

EQUIP 6484 LBS 6777 LBS 
POWER 443 WATTS 355 WATTS 
TOTAL 6638 LBS 6901 LBS 


* INCLUDED AS PUMP POWER IN ANALYSES, HOWEVER, MOST OF POWER 

(71.9 WATTS) PROVIDED BY WASTE HEAT 

** PUMPED SYSTEM ONLY 


Figure 4.3-15. Two-Phase Ammonia High Temperature System Schematic 
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Figure 4.3-16 Low Temperature Two-Phase Ammonia System 



107 


D1 80-27935-2 



TOTAL 


PUMPED CAPILLARY 
EQUIP 2472 LBS 2533 LBS 
POWER 1 1 0 WATTS 68 WATTS 
TOTAL 2510 LBS 2607 LBS 


• INCLUDED AS PUMP POWER IN ANALYSES, HOWEVER. MOST OF POWER 

(36J9 WATTS) PROVIDED BY WASTE HEAT. 

** PUMPED SYSTEM ONLY 


Figure 4.3- 17 Two-Phase Ammonia Low Temperature System Schematic 
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weights as a function of fluid temperature changes for a radiator inlet temperature of 
80°F. (The details of the weight calculations were described in the previous sections.) 
The fluid temperature change is constrained by the 40°F humidity control temperature 
and the 32°F freezing point of water in the pressurized module loop. The total system 
weight reaches a minimum at the 32°F battery cold plate outlet temperature limit. Fig- 
ure 4.3-19 shows the pumped ammonia system element weights for identical 80°F radi- 
ator inlet temperature. In this case the optimum fluid temperature change occurs before 
the 32°F battery cold plate outlet temperature limit is reached. 

Figure 4.3-20 shows the minimum system weight as a function of radiator inlet tem- 
perature for ammonia and Freon systems. The 80°F inlet temperature is close to opti- 
mal for both fluids. Detailed schematics for the optimum (80°F radiator inlet) Freon 11 
and ammonia pumped loop systems are shown in figures 4.3-21 and 4.3-22, respectively. 

4.3.8 Effect of Two-Phase Water System in Pressurized Modules 

The interface between the two-phase heat transport bus and the pumped water loops in 
the pressurized modules results in a lowering of the bus temperature in order to mini- 
mize system weight. The reason for this is that the water temperature change must be 
less than the temperature difference between equipment and bus. Consequently, since 
the water loop transports sensible heat, higher flow rates (and higher weights) are in- 
curred as the temperature difference decreases. A two-phase water heat transport sys- 
\ 

tern allows a higher bus temperature and potentially lighter weight system. 

4.3. 8.1 Two Phase Water Heat Exchanger and Line Sizing 

The two phase heat exchanger weights were based on the analysis outlined in section 
4.3.4. 1. Because the water vapor density is low for the temperature range considered, 
the vapor pressure drop (in the vapor line between the equipment and interface heat 
exchanger) effect on vaporization (condensation) temperature was included in the 
analyses. 

For the high temperature heat rejection system case the vapor line was fixed at an inside 
diameter of 2.25 inches and the liquid line at 0.5 inch inside diameter. These line sizes 
result in an overall head difference of about 1 inch, which is compatible with capillary 
pumping. The vapor line pressure drop produces a difference between vaporization tem- 
perature, at the equipment heat exchanger, and condensation temperature, at the inter- 
face heat exchanger, of 1.76°F. The heat exchangers were optimized as a function of 
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Figure 43-20 Optimized Total System Weight for Pumped Liquid Heat Transport System 
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EQUIP 11,343 LBS 

POWER 1710 WATTS 

TOTAL 11,941 LBS 


Figure 4.3-21 Pumped Liquid Freon-li System Schematic 


113 



D180-27935-2 



7J8 WATTS TOTAL 

EQUIP 10.137 LBS 

POWER 660 WATTS 

TOTAL 10,368 LBS 


Figure 4.3-22 Pumped Liquid Ammonia System Schematic 
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equipment to bus temperature difference that included this fixed vaporization tempera- 
ture difference. 

The effect of pressure drop on vaporization temperature is more pronounced in the low 
temperature heat rejection case. In this case the vapor line size was optimized in con- 
junction with heat exchanger optimization to provide the lowest weight system for a 
given humidity control unit to bus temperature difference. The liquid line size was fixed 
at 0.25 inch O.D. with 0.02 inch wall. 


4.3.8.2 Effect on System Weight 

Figure 4.3-23 shows the effect of incorporation of two-phase water heat transport sys- 
tems in the pressurized modules on the high temperature two-phase ammonia system 
element weights. The minimum total weight now occurs at a bus temperature of 79°F 
compared to the 70°F optimum for the system with pumped water loops. A detailed 
schematic showing the effects on the two-phase water system is shown in figure 4.3-24. 
The main bus sizes and weights remain unaffected. The equipment cold plate weights 
are increased due to the higher bus temperature. The radiator and pressurized module 
component weights are significantly reduced. The total system weight is 828 pounds less 
than that for the system with pumped water loops. 

The effects on the low temperature heat rejection system are shown in figures 4.3-25 
and 4.3-26. The optimum bus temperature for this case is 37.5°F compared to 36°F for 
the case with pumped water loops. As in the high temperature case the bus weight re- 
mains unaffected, the battery cold plate weight is increased and the other component 
weights are reduced. The total weight is 79 pounds less than that for the pumped water 
loop system. 

4.3.9 Cost and Benefits Analysis 

In the final report of the study completed in April of 1983 a cost and benefits assessment 
was given for developing thermal storage systems for both pumped liquid and two-phase 
heat transport concepts. The result indicated that those technology advancements were 
among the most desirable of the ones identified in that study. It was indicated in that 
study that development costs for the two-phase system would be 50% higher due to the 
complexity of: 
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Figure 4.3-23 High Temperature Two-Phase Ammonia Bus with Two-Phase Water Loops 
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Figure 4.3-24 Effect of Two-Phase Water Heat Transport System on High Temperature Bus 
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Figure 4.3-25 Low Temperature T wo-Phase Ammonia Bus with Two-Phase Water Loops 
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Figure 4.3-26 Effect of Two-Phase Water Heat Transport System on Low Temperature Bus 
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1. Phase change material packaging. 

2. Thermal interface with the heat transport system. 

In the current study a further assessment of the pumped liquid versus two-phase heat 
transport system was conducted. Two technologies were identified for advancement 
specifically to support the development of a two-phase system. These are— 

1. Two-phase water thermal transport loops for inhabited environment. 

2. Heat exchanger for liquids in nearly saturated state in zero gravity. 

The quantifiable benefits of these advancements are that the two-phased system is less 
complex than the pumped liquid system; that the two-phased system weighs less than the 
pumped liquid system and that means lower cost to transport the system to orbit; and 
finally the area of the radiator is less for the two-phased system and that means the 
assembly labor costs will be lower. 

The two systems compared are given by the pumped Freon- 11 system of figure 4.3-21 
and the pumped two-phased water heat transport system of figures 4.3-24 and 4.3-26. 

The complexity factors were compared using the RCS PRICE modelling technique and 
the result came out $21.26M for the liquid and $16.08M for the two-phased that results 
in $5.18M in favor of the two-phased system. 

The transportation costs were calculated using $718. per pound to orbit and the differ- 
ence in system weights. This resulted in $2.66M in favor of the two-phased system. The 
assembly costs were based on $77,000 per 24-hr day for astronaut time and the assess- 
ment which was used in the last study of 8 labor hours to assemble 100 square feet of 
radiator. This resulted in a $475,000 saving for the two-phased system. 

The cost of advancing the technologies involved has been estimated to be $0.8M for the 
heat exchanger program and $2.59M for advancing the two-phased water interior loop 
system (assuming use of shuttle test data for heat pipes rather than a complete indepen- 
dent flight test). Together these represent an expense for technology advancement for a 
two-phased heat transport system of $3.4M. 
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Using the above figures the cost over benefit ratio of advancing technologies to support 
the two-phased heat transport system is 0.41. This is based on the $3.4M advancement 
cost divided by $8.32M benefits. 

4.4 SUMMARY OF RESULTS 

The weights for the various heat transport systems, applied to the baseline space station, 
are summarized in table 4.4-1. The pumped two-phase ammonia system used in con- 
junction with two-phase water heat transport inside the pressurized modules is the light- 
est system. The corresponding capillary two-phase system is 359 pounds heavier. The 
pumped two-phase system with pumped water loops inside the modules is 907 pounds 
heavier. The pumped liquid ammonia system is heavier by 2,126 pounds and the pumped 
freon system is heavier by 3,699 pounds. The total radiator area required is: 6186 ft 2 
for two-phase ammonia systems in conjunction with two-phase water loops; 6690 ft 2 for 
two-phase ammonia systems with pumped water loops; 7900 ft 2 for pumped liquid am- 
monia system; and, 8035 ft 2 for pumped freon system. 

4.5 CONCLUSIONS 

A pumped two-phase heat transport system provides approximately a 1000 lbm weight 
reduction and power and size reductions compared to a pumped liquid loop system. More 
importantly, the two-phase system offers greater flexibility in configuring the space 
station. 

A capillary two-phase heat transport system offers the advantages of a pumped two- 
phase system with a relatively small weight increase. The capillary system does not 
need the pumps, valves and controls needed for the pumped two phase system. Conse- 
quently a capillary system is, in principle, a more reliable system. 

For pressurized modules, a t.wo-phase water heat transport system rather than liquid 
water system provides an additional weight savings when used with a. two-phase main 
transport system. A capillary two phase water system could potentially increase relia- 
bility and reduce vibration and noise. 

Alternative pumping concepts for the pumped two-phase system were considered briefly. 
One concept uses an osmotic pump in place of the baseline mechanical pump. This 
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concept provides pumping by osmotic pressure that causes solvent to flow through a 
semipermeable membrane into a solution which flows to the evaporator. This concept 
requires auxiliary mechanical pumps to keep the solution from being diluted next to the 
membrane. The weight, reliability, and performance deficiencies of this concept elimi- 
nates it from serious consideration as an alternate pumping scheme. The other concept 
considered was an ion drag pump that produces fluid flow by creating ions in a corona 
discharge. The ions are accelerated in an electric field and impart momentum to the 
fluid. This scheme has the advantage of pumping with no moving parts. However, the 
pumping efficiency is only about 10%, high voltages are required, transport fluid must be 
a dielectric, and the corona discharge may have degrading effects on the fluid and 
electrode. 1 

4.6 RECOMMENDATIONS 

The results of the study showed that the weight of a two-phase heat transport system is 
approximately 1200 lbm less than that of a comparable single-phase system of identical 
capacity. This 12% lower weight alone would probably to be sufficient justification for 
the selection of a two-phase system for the space station. The most compelling reasons 
for the choice of a two-phase transport system are (1) flexibility in locating heat loads 
and reconfiguring experiments, (2) modular growth of the station, and (3) stable tempera- 
ture interface with cooling and heating loads over an inside range of operating 
conditions. 

The two-phase system concept, however, has some inherent technical risks that will 
require expensive space flight testing to resolve. The developmental costs of the two- 
phase system would therefore be expected to be considerably greater than the cost of 
developing a single-phase system. 

Additional information is needed before a sound decision can be made as to which 
thermal transport system should be selected for the initial space station. It is therefore 
recommended that a program be initiated to generate the necessary information to sup- 
port the selection of a space station thermal transport system. A three-step program is 
envisioned. In the first step, system requirements would be established. These require- 
ments would stem from the definition of (1) system loads such as experiments, equip- 
ment, etc. (2) planned space station evolutionary growth, and (3) space station mission 
planning. 
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Candidate single- and two-phase transport system would be designed and optimized in 
the record program step. These systems would be developed for a baseline station and 
mission drawn from the step one requirements definition study. Dollar cost benefits of 
each transport concept would be quantified for all important system attributes including: 

1. Mass. 

2. Size. 

3. Flexibility and growth. 

4. Reliability. 

5. Maintainability. 

6. Constructability. 

7. Operation costs. 

In the third step, detailed plans for transport system development would be prepared. 
Developmental costs would then be predicted and a cost and benefit analysis performed 
to identify the best thermal transport system concept. 

Regardless of the final selection of the thermal transport system concept for the space 
station, the potential benefits of the two-phase systems warrant immediate technology 
development. Such developments are necessary to bring the level of technical maturity 
up to the point required for space station preliminary design. Because a pumped two- 
phase thermal bus system development program is currently in progress under NASA JSC 
contracts NAS9- 16781 and NAS9- 16782, it is recommended that emphasis should be 
placed on development of a two-phase transport loop suitable for thermal management 
within pressurized inhabited environments of the space station. The high-performance 
fluids (ammonia or freon) envisioned for use in the main thermal transport bus cannot be 
used in inhabited areas due to their toxicity. Water would be the first choice for the 
working fluid in the internal transport loop. A two-phase design would provide the flexi- 
bility, modular growth capability, and isothermal interface characteristics desired for 
the overall thermal management system. Both mechanically pumped and capillary 
pumped loops should be investigated. Special emphasis should be placed on developing 
pump and heat exchanger technology that would benefit both the main bus and internal 
transport loop concepts. In addition, capillary pumping for the main thermal transport 
system should be investigated because of the potential for increased reliability and re- 
duced power, noise, and vibration by eliminating mechanical pumps. Volume III provides 
preliminary plans for the accomplishment of these advances. 
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5.0 INTEGRATION OF AUTOMATED HOUSEKEEPING 

This section presents the results of the study conducted to characterize a system for 
integrating the automation of several housekeeping subsystems on an inhabited space 
station. This integration system will be a step toward meeting the automomy /auto- 
mation philosophy for the space station which has been defined by the Concept Develop- 
ment Group (see table 5.1-1). 

5.1 INTRODUCTION 

In the Advanced Platform Sytems Technology Study completed in early 1983, the cost 
versus benefits of integrating the automation of several utilities producing subsystems on 
a space station was assessed. The results of this assessment gave indication that the 
function of providing this integration could produce savings to the space station over a 
10-year life of $184M. The same study indicated that a large part of the cost of such a 
system would be the software development and the probable use of expert systems tech- 
nology. These cost figures were assessed as being about $9M. Because the system had 
not been described at a detailed level and because the cost/benefits were impressive, it 
was decided to conduct the current study to take a more detailed look at the functions of 
such a controller. The current study also produced a reassessment of 'the cost and bene- 
fits of the system and generated a more definitive identification of the applicability of 
expert systems to the process. 

The following paragraphs report on the approach, results, conclusions, and recommenda- 
tions resulting from this characterization study and also provide a technical discussion of 
the study elements. 

5.2 APPROACH 

The objective of this study was to obtain a characterization of the Integrating Manage- 
ment Controller to allow a better understanding of the benefits possible and the tech- 
nology needed for implementing such a controller so that it will provide reliable, real- 
time management of the separate housekeeping controllers on a space station. To 
accomplish this objective the results of the initial study were extended by a more 
detailed modeling of how a management type controller might be employed. The model 
was then examined to identify options in the implementation which better defined the 
benefits to be obtained from the integration process. 
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Table 5.1-1 

Space Station Autonomy/ Automation Philosophy 


Subsystem/system monitoring and control will be performed on board. 

Systems monitoring and control will be automated. 

Fault detection and isolation will be an automated function for all subsystems. 

Redundancy management including reconfiguration will be performed automatically on 
board. 

Reverification of systems/subsystems elements will be performed automatically on 
board. 

Operations planning and scheduling will be performed on board. 

The degree of automation will increase as the space station grows and technology 
becomes available. 

Collection and analysis of trend data will be automated. 

The space station platform shall have the same degree of automation on board as the 
manned base. 
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The following paragraphs indicate in some detail the approach steps used in this study. 



5.2.1 Update the Housekeeping Functions List 


In performance of this subtask a system analysis was conducted to update the following 
list of functions to be performed by each of the three automatic housekeeping subsystem 
controllers: 

Table 5.2-1 

Functions For Housekeeping Controllers 


Electrical Power 

Control voltage at power 
user outlets. 

Control power levels at 
power user outlets. 

Switch sources based on 
sensed status of sources 


Thermal 

Control temperature to 
set points within cabins. 

Control temperature at 
heat exchangers for 
specific equipment items. 

Control humidity of cabin 
atmosphere. 


Life Support 

Control oxygen and nitro- 
gen supplied to cabin. 

Control contamination 
level in cabin air. 

Control quality of potable 
and wash water. Removal 
of CC>2 from cabin air. 


The above list indicates the starting point on independent control functions within each 
of the three housekeeping subsystems on the space station considered in this study. 
These functions are those which relate to maintaining environment on the space station 
for the crew and for the mission peculiar equipment. In this subtask the list was ex- 
panded for models of the three subsystems to the level of detail where the control 
parameters would be sensed. 


To accomplish this expansion, a review was conducted of thermal control automation 
progress reports, of briefing material for power system automation (MCR-82-631 dated 
2-9-83), and of Space Station Environmental Control and Life Support System— Prelimi- 
nary Concept Design Report (3SC- 17727). This review extracted descriptive information 
about those subsystems and their automation that was used to identify the following: 


127 





D180-27935-2 


1. Functions performed by automation of the subsystems. 

2. Quantities which would need to be sensed in order to perform the automation. 

These items were then listed and are presented as tables 5.3-1, 5.3-2, and 5.3-3 of this 
final report. Use of this information was made in the next step of the study as described 
in the next paragraph. 

5.2.2 Define Functions to Integrate the Automation of the Housekeeping System 

A systems analysis was performed to develop a concept for integrating the control of the 
three housekeeping functions and to identify the control parameters involved. The anal- 
ysis process used the control functions list developed by the review described above and 
identified where the items on the list had relationship to the control of another sub- 
system. Outside events, which can effect control of the housekeeping subsystems, were 
then identified. Using these lists of functions and data, the functional concepts for the 
integrating controller were developed. Figure 5.3-2 shows the relationships considered 
and lists the outside events considered. 

Based on the interactions identified by the above process functions were identified for 
the integrating controller. Functional block diagrams were then developed along with 
functional descriptions of each of those identified. These functional block diagrams and 
descriptions are also presented under section 5.3 of this report. 

5.2.3 Identify Integration Functional Scenarios 

Because various mode shifts would be selected and implemented by an integrating con- 
troller, it was necessary to identify the mode shifts and to assess the sequencing of the 
action. The scenarios for operation of an integrating controller were conceptualized in 
this subtask by a systems analysis approach. The scenarios were developed from the 
nominal and functional sequences listed below. 

1. Management of start-up modes. 

2. Management of load sharing for electrical power and thermal control 
according to astronaut usage patterns, suniight/darkside passages, and special 
events such as EVA or module reconfiguraiton activities. 

3. Management of emergency and redundant path modes. 

4. Management of material transfer and shutdown modes. 
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Table 5.3-1 

Electrical Power Subsystem Automation 


Functions 

o Control solar array orientation 

o Control of solar array selection - segment selections 
o Regulation of solar array output voltage - shunt regulation 
o Control of battery charge-discharge processes 

o Battery selections - cell selections 

o Load sharing control of regulators 

o Shunting for under use control 

o Redundancy Management within the electrical power system 

Sensed Quantities 

o Solar array temperatures 

o Solar array positions 

o Solar array voltages by sections of the array 

o Battery cell voltages 

o Battery cell temperatures 

o Battery cell pressures 

o Battery charge voltage 

o dc/dc converter line voltage 

o Transformer coupled converter output voltage 

o Series resonant inverter (dc/ac) output voltage 

o Series resonant inverter fuse status 

o Magnetic latching relay position 

o Cable temperature 
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Table 5.3-2 

Life Support Subsystem Automation 


02 Generation 


Functions 

o Control of the flow of water to the electrolysis units 
o Valve operation 
o Pump operation 

o Control of electrolysis current 

o Control of the flow of H 2 away from the unit 
o Valve operation 

o Control of the flow of water away from the unit 
o Valve operation 
o Pump operation 

o Control of the flow of oxygen away from the unit 
o Valve operation 

o Redundancy management within the O 2 generator 
o Detection of failure 

o Abnormal values of several quantities 
o Selection of redundant elements: generators/pumps/valves 

Sensed Quantities 

o Partial pressure of cabin O 2 
o Flow rate of input water 
o Pressure of H 2 at output 
o Flow rate of water at output 
o Pressure of O 2 in storage at output 
o Selected set point condition 

o Status of valves, pumps, generators and storage units 
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N 2 Supply 
Functions 

o Control of the flow of N 2 from storage 
o Valve operation 

o Redundancy management functions within the N 2 supply 
o Detection of failures 

o Abnormal values of several quantities 
o Selection of redundant valves 

Sensed Quantities 


o Cabin pressure 
o Pressure of N 2 storage tanks 
o Selected set point 
o Status of valves and storage tanks 
CO 2 Removal 
Functions 

o Position of by-pass valves to control air flow to beds 

o Position of by-pass valves to isolate beds for desorption from the cabin 

o Control of electric heaters to create steam to flow through beds being desorbed 

o Control of valves to direct CO 2 to the reduction system from the beds being 
desorbed 


o Control of valves to provide hygenic water for steam into desorbed beds 

o Redundancy management 

o Detection of abnormal sensed values 

o Selection of redundant elements: fans, by-pass valves, beds, and steam 
generators 
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Table 5.3-2 (Continued) 

Life Support Subsystem Automation 


Sensed Quantities 

o Partial pressure of cabin CO 2 
o Flow rate of water at input to steam generator 
o Pressure of CO 2 in accumulator at output 
o Temperature of steam in steam generator 
o Flow rates at desorbed bed 

o Status of beds being used for absorption and being desorbed 
o Status of valves and fans 
o Selected set point 
CO 2 Reduction 
Functions 

o Mixing of H 2 and CO 2 

o Flow of mixed CO 2 and H 2 through filter to the reduction unit 

o Pump and valve control for water accumulator at reduction unit output 

o Redundance management within the CO 2 reduction unit 

o Selection of redundant elements: reduction unit, valves, and accumulator 
o Failure detection based on abnormal sensed values 

o Cooling for unit 

Sensed Quantities 

o Flow and pressure of gases at input 
o Temperature of unit 

o Flow and pressure of gases at output of unit 
o Flow of water to accumulator 
o Capacity filled with water in accumulator 
o Flow of water out of accumulators 
o Status of valves and accumulators 
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Table 5.3-2 (Continued) 

Life Support Subsystem Automation 


Trace Contamination Control (TCC) 

Functions 

o By-pass valves to control air flow through beds 
o Annunciation of below normal bed status 
o Control of power to electric heaters 

o Redundancy management within the trace contamination control system 
o Failure detection based on abnormal sensed values 

o Selection of redundant elements: alternate fans, paths through beds, and 
oxidizer 

Sensed Quantities 

o Level of contamination 

o Temperature of oxidizer 

o Flow through units 

o Status of fans, valves, oxidizer heater and beds 
o Selected set point 
Potable Water Process 
Functions 

o Control of water flow to post-treat 
o valves 
o pump 

o Control of cycling in post-treat and Water Quality Monitor (WQM) 
o valves 
o pumps 
o WQM processes 

o Control of flow to selected storage tank 
o Control of iodine addition in storage tank testing process 
o Control of overflow to hygienic water 
o Control of water heater 
o Control of use flow out of storage tanks 
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Table 5.3-2 (Continued) 

Life Support Subsystem Automation 


Functions (Cont) 

o Redundancy management with the potable water processor system 
o Failure detect 

o Seclection of redundant elements: accumulators, water quality monitors, 
(WQM), tanks, valves, and beds 

Sensed Quantities 

o Capacity filled in accumulators 

o Measured contaminants in WQM 

o Capacity filled in storage, test, use tanks 

o Iodine level in storage tank test processing 

o Post treat valve and bed status 

o Water temperatures in system 

o Storage tank valve status 

o Water flow rates in system 

Hygenic Water Process 

Functions 

o Control of pre-treat pumping 
o Control of pre-treat biopal VRG 20 addition 

o Control of pumping and valving into the vapor-compression distillation (VCD) unit 
o Control of compression in VCD 
o Control of heating in VCD 

o Control of conductivity testing of VCD condensate and valving for output 
o Control of post-treat valving and pumping 
o Control of WQM processes 
o Control of flow to fill-use tanks 
o Control of flow out of fill-use tank 
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Table 5.3-2 (Continued) 

Life Support Subsystem Automation 


Functions (Cont) 

o Redundancy management within the hygenic water processor system 
o Failure detect 

o Select redundant elements: WQM, VCD, valves, fill tanks, pumps and heaters 
Sensed Quantities 

o PH level in pre-treat 
o Flows in pre-treat 
o Waste holding tank capacity filled 
o Valve status indicators 
o Waste tank capacity filled 
o Sludge tank capacity filled 
o Flows into VCD 
o Pressure in VCD 
o Temperature in VCD 
o Conductivity of VCD condensate 
o Flow of condensate from VCD 
o Measured contaminants in WQM 
o Post treat valve and bed status 
o Flow rates in post treat and storage 
o Storage tank valve status 
o Capacity filled in storage tanks 
o Capacity filled in accumulators in system 
Wash Water Process 
Functions 

o Control of pumping to work holding tank 
o Control of pumping and valving to hyper-filtration process 
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Table 5.3-2 (Continued) 

Life Support Subsystem Automation 

Functions (Cont) 

o Control of heating in hyper-filtration process 

o Control of valving and pumping from the hyper-filtration process 

o Control of the addition of sodium hypochlorite in post-treat 

o Control of the addition of iodine in post-treat 

o Control of pumping and valving for post-treat 

o Control of pumping and valving for storage of wash water 

o Redundancy management within the wash water processor system 
o Failure detection 

o Selection of redundant elements: pumps, valves, hyper-filtration units, and 
tanks 

Sensed Quantities 

o Flows to and from holding tank 
o Flows to and from the hyper-filtration processor 
o Temperature of hyper-filtration processor 
o Capacity filled in holding tank 
o Capacity filled in hyper-filtration process 
o Measured contaminants in WQM 
o Post-treat valve and bed status 
o Flows for post-treat and to storage 
o Storage tank valve status 
o Capacity filled in storage tanks 

o Quantity of iodine and sodium hypochlorite available for use 
o Capacity filled in sludge tank 
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Table 5.3-3 

Thermal Control Automation 


Functions 

o Control of cabin air flow through heaters 
o Control of heaters 

o Control of heat exchanger condensate flow to separators 
o Control of water flow out of separators 

o Control of positions of steerable radiators or selections of selectable radiators 

o Control of coolant flow - valve positions or pump speeds 

o Redundancy management within the thermal control system 
o Sensed failures from abnormal sensor values 

o Selection of redundant elements: fans, heaters, heat exchanges, separators, 
pumps, and valves 

Sensed Quantities 

o Temperature of cabin air 

o Humidity of cabin air 

o Input air flow to heater 

o Condensate flow at heat exchanger 

o Water flow out of separators 

o Air flow out of separators 

o Heater temperature 

o Set point status 

o Equipment status 

o Position and rate information for steerable radiator servos 
o Valve positions 
o Pump speeds 
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5. Management of maintenance scheduling and interaction with normal or 
emergency modes. 

The subtask was conducted at a conceptual level and the results indicated that the sce- 
narios simply reinforced the functional descriptions already being developed under the 
previous subtasks. In addition it was determined that scenarios of significant detail 
would require a rather complete description of space station configurations, missions and 
operations. In the absence of such, the scenarios developed were general in nature. 
Tables of section 5.3.4. 1 give the scenarios that were developed. 

5.2.4 Identify Hardware and Software Elements of Integrating Controller 

A systems analysis was conducted in cooperation with data management specialists to 
identify hardware and software elements of a concept for an integrating controller for 
automated housekeeping functions and to isolate technologies to be considered for ad- 
vancement in order to implement the concepts. The use of artificial intelligence in the 
form of expert systems was explored to implement the flexibility and tolerance for 
change needed in this integrating controller. 

The following questions were poised for the Data Management technical specialists on 
artificial intelligence: 

1. Does this concept appear to need expert system implementation? 

2. If it doesn't need it, would it benefit from it? 

3. Describe how expert systems could be used in implementing this concept. 

4. How many rules would be used in your estimation to implement the concept? 

5. How much of the implementation would be on space station computers and 
how much would be in a ground installation? 

6. What would be the characteristics of a space and ground computer system? 
Memory? Thru put rate? Anything else? 

7. Describe the magnitude of development effort needed to achieve an expert 
system of the type needed for this concept; $ needed; years needed. 

The answers received are given in section 5.3.6 of this report. In addition, figure 5.3-10 
gives an initial cut on how the processing for an integrating controller might be grouped 
functionally in hardware systems both on board the space station and on the ground. 
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5-2.5 Compare Trade Study Results 

The implementation options and system characterizations were analyzed to compare the 
benefits associated with the several functions identified for the integrating controller. 
This benefits comparison was based on the following considerations: 

1. What is the extent of use of the function during space station operations? 

2. Is an interactive mode using the function desirable or should it be fully 
automated? 

3. Is the function essential for safety? 

4. What is the extent of deterministic problem solving? 

5. Does use of the function appear to increase with mission experience? 

Section 5.3.7 gives the tabulation of this comparison and gives the resulting ranking of 
the benefits of implementing technologies for these functions. 

Assessments of benefits of options for trade in areas architecture, on board versus 
ground processing, and human interaction versus fully automatic were also made. These 
assessments are also reported in section 5.3.7. 

Finally a review of the cost and benefits ratio for expert system technology developed in 
the Advanced Platform Systems Technology Study was conducted and is reported in sec- 
tion 5.3.8. 

5-2.6' Identify Technologies for Advancement 

This subtask produced specific recommendations on the expert systems technologies 
advancement to support the development of an integrating controller for a space station. 
These technologies were identified at the level of specific procedures for advancement 
and this is discussed in section 5.3.9. 

5.3 TECHNICAL DISCUSSION 

This section presents in a detailed discussion of the study outputs along with the associ- 
ated data and conceptual illustrations. The output discussion given by the following 
paragraphs are structured according to the sequence of the approach subtasks. 
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5.3.1 Automated Housekeeping Functions 

The automation of three subsystems on an inhabited space station was investigated to 
identify the functions to be performed and the sensing that would be needed. The three 
subsystems were electrical power, life support, and thermal management and the auto- 
mation being considered through this subtask is that which would be used internal to each 
of these subsystems in order that they can perform their functions automatically. The 
integration of these automated systems deals with interactions between them, with out- 
side factors that affect them all or with trends that involve more than one subsystem. 

The electrical power and thermal subsystem automations are fairly well understood and 
are also the subjects of separate NASA study contracts. For those reasons we used re- 
ports on the subjects to identify automation elements and these reports were: (1) MCR 
82-631 "Power subsystem automation study" Briefing for program review and (2) Rock- 
well Monthly Progress Reports - NAS9- 16782 "High Efficiency Automated Thermal Con- 
trol System Program". 

The life support subsystem on the other hand is in a conceptual state and the extent of 
expendable resupply versus onboard regeneration and the amount of automation that is 
practical are still unresolved issues. At present the life support concepts are being 
developed and the components are operated separately but not as an overall system. 
Figure 5.3-1 is an overall system concept which is reported in 3SC- 17727, "Space Station 
Environmental Control and Life Support System Preliminary Conceptual Design" DOC 
CSD-SS-059, dated 9/82. This concept was used to facilitate our identification of life 
support automation functions, but it is only one of several concepts and will undoubtably 
by modified before the space station baseline is established. 

Referring to figure 5.3-1, the function of the system can be separated into: 

1. Oxygen generation. 

2. Nitrogen supply. 

3. Carbon dioxide removal. 

4. Carbon dioxide reduction. 

5. Trace contamination control. 

6. Potable water processing. 

7. Hygenic water processing. 

8. Wash water processing. 
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Figure 5.3 - 1 Schematic for Space Station Life Support Subsystem 
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These along with the cabin temperature and humidity control supported by the thermal 
management system are to provide the life supporting environment inside an inhabited 
space station in a regenerative sense. The automation functions and sensing for life 
support are identified in our study for each of these categories. Tables 5.3-1 through 

5.3- 3 give the results of analysis conducted of these subsystem concepts and lists the 
functions and sensed quantities for the automations identified. 

The functions and sensed quantities in these tables were then used to construct an inter- 
face tabulation (see fig. 5.3-2) to identify when interactions between the automated 
subsystems could exist and where outside events could influence the overall operation. 
These identifications lead to the definition of functions for the integrating controller. 

5.3.2 Integrating Controller Functions 

The integrating controller is a concept that is intended to provide management level 
control of automated utilities subsystems on a manned space station. Initially this con- 
troller would be largely an advisory service for the astronauts. As such, it would tend to 
replace the advisory service which has been provided by mission control with a more 
autonomous interactive system that the astronauts can use on board. Because there will 
be actions that will be repetitive and bothersome to the astronauts it is a worthy goal to 
seek a fully automatic integrating controller for some functions. 

This final report section gives some detail on the identification of functions to be per- 
formed by such an integrating controller. Based on the interactions shown by figure 

5.3- 2, it is clear that the three subsystems affect each other significantly and that there 
are outside factors that affect them all. The functions performed by an integrating 
controller would then deal with those interactions. Inspection of these indicate the fol- 
lowing: 

1. Electrical power load management is needed because both thermal and life support 
are heavy power users and reduction of their usage to balance loads needs to con- 
sider their interacting functions. 

2. Materials transfer management is needed because outside factors affect the loca- 
tion of needs as well as the location of the availability of life support materials 
around the space station. In many cases transfers need to be considered against 
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scheduled events and against dumping constraints as well as impacts on power and 
thermal loading. 

3. Intersubsystem failure isolation is needed because failure diagnosis outside of 
subsystem boundaries will have to be conducted in order to trace the cause through 
the interacting functions, e.g. an apparent failure of the separator in the 
thermal/humidity control system could be caused by an actual failure in the Water 
Quality Monitor (WQM) in the life support that is producing a backup into the 
accumulator receiving the condensate from the separators. In this case failure 
isolation within a subsystem would not be sufficient to find the problem. 

4. Intersubsystem redundant path selection is needed because selection of redundant 
paths in response to failures or maintenance shutdown will have to consider the 
impact on interacting subsystems. 

5. Maintenance schedule management is an integrated function since changes to the 
timing of maintenance actions for one subsystem can have affects on the operation 
and maintenance of other subsystems. This is because maintenance may cause 
temporary shutdowns and may result in changes in performance of the maintained 
subsystem that affect others. 

6. Startup integration is needed to control the interdependent sequencing of bringing 
subsystems on line so that outputs are available before the need is created. 

The following paragraphs give a more detailed description of each of these functions. 

5.3.3 Functional Descriptions 

The integrating controller described here is an overall management controller that proc- 
esses data and commands functions that effect the automation of the following space 
station utilities producing subystems: electrical power, life support, and thermal con- 
trol. It is assumed that each of these subsystems is automatically controlled within 
itself to track references in the presence of disturbances that effect the controller vari- 
ables. The integrating controller then will basically change the references to these auto- 
matic controllers or change the configuration of the automatic controllers or of the 
subsystems being controlled in an orchestrated or integrated manner. Figure 5.3-3 shows 
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Figure 5.3-3. Interfaces Between an Integrating Controller and Automated Housekeeping Subsystems 
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the overall relationship of the integrating controller to the separate automated sub- 
systems. 

The functional goal of the integrating controller is to manage the interactions between 
the separate automated housekeeping subsystems so that the overall system may con- 
tinue to operate through events or conditions that are not nominal. The controller will 
not attempt to maintain the subsystems at specific performance levels through these 
anomalies, but rather will select a response to the anomaly which will be determined by 
the controller to be most workable. The controller will consider current as well as sche- 
duled tasks of each of the subsystems. It will also consider levels of criticallity of the 
separate subsystems based on life support of the crew and support of the mission and it 
will consider the status of subsystems being controlled as well as expected loads on each 
when making its determinations. The following paragraphs describe major functions of 
an integrating controller. 

5.3.3. 1 Electrical Power Load Management. 

Figure 5.3-4 shows a block diagram for the electrical power load management part of an 
integrating controller's function. For this function, the integrating controller receives 
data that shows that the loads imposed on the electrical power subsystem are greater 
than the supply. These data could be dropping voltages or rapidly decreasing battery 
charge level. 

The integrating controller will establish initial priority for those loads which are on line 
in the housekeeping area. Table 5.3-4 shows an example of such an initial priority list. 
Table 5.3-5 gives criteria that are used in determining the initial priority of loads. The 
integrating controller then adjusts the priorities for predicted load requirements and also 
adjusts according to the status of the subsystem using the power, e.g., the level of pro- 
duced material that is, in storage, the maintenance status or the failure probability status 
for that subystem. This adjusted priority list will be examined to determine which loads 
may be either shut down or reduced. The loads that can be shut down or reduced are so 
commanded and a time assessment is made by the controller to determine when the loads 
need to be resumed. The controller then manages switch on and switch out of loads 
through the period of power deficiency. It also makes the determination on whether 
degraded or emergency life support modes are necessary, and sets changes to limits on 
the individual life support subsystem and thermal control references as needed. In addi- 
tion, the controller commands annunciation of conditions that relate to those changes in 
the life support modes. In summary, the subfunctions of power load management are: 
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Figure 5.3-4. Functional Block Diagram for Electrical Power Load Management 
by an Integrating Controller 
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TABLE 5.3-4 

Example of Load Priorities# 




1. Power to water electrolysis generator for O2* - valves, pumps fans, electrolysis 
current. 

2. Power to CO 2 removal units - valves, pumps, fans, steam heaters. 

3. Power to dehumidifiers fans, pumps, valves, separators. 

4. Power to cabin air heaters. 

5. Power to Hygenic Water System* (this is placed fairly high on the list because, if 
production is low there would be a deficiency of hygiene water for 0 2 generation and 
CO 2 removal) - valves, pumps, VCD compressor, VCD heater and WQM. 

6. Power to TCC unit (oxidizer, heater, fans, valves). 

7. Power to CO 2 reduction unit (valves, pumps). 

8. Power to wash water system* (valves, pumps, hyperfiltration heater, WQM, water 
heater). 

9. Power to potable water system* (valves, pumps, WQM, water heater). 

^Each item on list moves up in priority if high power need is coming up, but moves down 

if current need will be reduced in the near future. 

♦Each with full level of output substance moves down in priority list with respect to any 

which is depleted. 
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TABLE 5.3-5 

Example of Criteria for Functional Criti cal li ty 

1. Required to sustain the life of the crew. 

2. Short time allowed without replacement of life sustaining function. 

3. Required to maintain continuity of the mission. 

4. Short time allowed without replacement of continuity maintaining function. 

5. Required to sustain functions of more critical systems. 

6. Short time allowed before replacement of sustaining functions. 

7. Desired to maintain comfort status of crew. 

8. Short time allowed without replacement of comfort maintaining function. 
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1. Receive data on power deficiency. 

2. Determine loads to be reduced or shut down. 

3. Prepare system for shut down or reduction. 

a. Transfer of materials in storage. 

\ 

b. Closure of cabins. 

4. Select degraded or emergency mode if needed. 

5. Annunciate to crew. 

6. Implement action. 

7. Monitor time and change loads as needed to maintain system balance. 

5.3.3.2 Materials Transfer Management 

Figure 3.5-5 shows a block diagram for this function of an integrating controller. In 
order to perform this function, the integrating controller will receive data on the levels 
of water, oxygen, nitrogen, hydrogen, CO 2 and any other materials stored in various 
places around the space station. /These data will be compared by the integrating control- 
ler with the schedule and location oriented needs for the materials. Any necessary 
transferral of such materials about the space station will then be determined and com- 
manded. These determinations will be based on established schedule and location 
requirements for material as modified by up-to-date anomaly information. The onboard 
transferrals accomplished by this function will allow the space station to share onboard 
resources in the most effective manner to survive failures or disruptive events such as 
sustained concentrations of the crew or science experiments in a particular part of the 
space station. This material transfer process will be an integral part a s necessary of any 
power shut down, redundant path selection, or maintenance rescheduling action by the 
integrating controller. Close off of modules or configuring for degraded or emergency 
modes will also be attended by materials transfer determinations and commands provided 
by the controller. In the event or over supply, the integrating controller will determine 
if dumping is an appropriate solution as well as where and when. 

A summary of elements of this function include: 

1. Data gathering on storage levels around the space station. 

2. Determination of materials transfer needs against schedules or against loca- 
tions. 

3. Command actual transferrals. 

4. Monitor time for follow-up transferrals back as necessary. 

5. Decisions on the dumping of materials. 
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Figure 5.3-5. Functional Block Diagram for Materials Transfer Management by an Integrating Controller 
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a. Location of dumping. 

b. Time of dumping. 

c. Alternates to dumping. 

5.3.3.3 Intersubsystem Failure Isolation 

This function of an integrating controller will be performed after a fault goes undetected 
through the fault isolation processes within the subsystems. This diagnostic function will 
consider failure indications across subsystem boundaries and will be largely interactive 
with the onboard crew to help them trace down those failures. The function will have 
numerous paths that will be followed in response to inputs from the astronauts to iden- 
tify the fault and recommend the corrective action. Figure 5.3-6 illustrates how such a 
function could be structured. A summary of elements of this function include: 

1. Data gathering on existence of inter-subsystem fault. 

2. Annunciation to crew. 

3. Interactive process with crew to isolate fault. 

4. Annunciate recommended action to crew. 

5. 3.3.4 Intersubsystem Redundant Bath Selection 

Figure 5.3-7 shows a functional block diagram for the redundant path management part 
of the integrating controller process. For this, the controller receives data indicating a 
failed element in one of the automated housekeeping systems. The controller will survey 
the configurations existing to determine if a redundant path is available. This will be 
done considering any previous failures not repaired or redundant path selections for 
maintenance shut downs which may be in effect. Then available paths will be selected, 
but preparations will first be commanded by the integrating controller as needed. These 
include transfer of materials such as water from a system to be shut down to one that 
will experience extra use during the failure, power adjustments, and modifications to the 
maintenance schedule. Then the switch of function will be made to the redundant path. 
In the event that a redundant path is not available or will only be available for a limited 
time (due to materials shortages or essential maintenance schedules), the integrating 
controller will decide if a degraded or emergency mode with or without cabin shut down 
is needed. It will then annunciate the mode or shut down to the crew and will command 
and materials transfer and power adjustments needed to prepare for the selected mode. 
The limits on the individual life support subsystem or thermal references will be adjusted 
to levels consistent with the selected mode shift. These functions of the integrating 
controller are summarized by the following: 
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Figure 5.3-6. Functional Block Diagram for Inter-Subsystem 
Failure Isolation Using Integrating Controller 








Figure 5.3-7 Functional Block Diagram for inter-subsystem Redundant Path Selection 
by an Integrating Controller 
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1. Receive data on failed system path. 

2. Determine if redundant paths are available. 

3. Prepare system for switch to the redundant paths. 

a. Transferral of materials. 

b. Adjustment of maintenance schedules. 

c. Power usage adjustments. 

4. Select degraded or emergency mode if needed - perform necessary adjust- 
ments. 

5. Annunciate to crew. 

6. Implement action. 

5.3.3.5 Maintenance Schedule Management 

This function of the integrating controller is displayed by the block diagram of figure 
5.3-8. The normal maintenance schedule for all housekeeping subsystems will be estab- 
lished prior to space station deployment. (Usually as the station is being developed.) The 
integrating controller will annunciate maintenance actions periodically to the crew in 
accordance with that schedule. The controller will also command appropriate adjust- 
ments to the subsystems; i.e., power shut downs, materials transfers, or redundant path 
selections on schedule to prepare for the normal maintenance actions. Based on data 
collected on failure modes, operational conflicts, maintenance supply logistics problems, 
or astronaut time conflicts, the normal schedule may be modified by the integrating 
controller using coordinated adjustments. Thereafter, the controller will manage 
maintenance accordingly and will determine any modifications needed in the logistics 
requirements for maintenance materials or manuals. These functions are summarized by 
the following: 

1. Receive data on schedule problem. 

2. Determine if schedule problems are: 

a. caused by system failures. 

b. incompatibility with operations. 

c. failure to serve maintenance needs. 

3. Determine schedule change and impacts. 

4. Determine logistics changes needed. 

5. Annunciate to crew. 

This function will be largely interactive with the onboard crew and the integrating con- 
troller will be receiving inputs and providing outputs through an interactive terminal. 
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Figure 5.3-8. Functional Block Diagram for Maintenance Schedule Management by an Integrating Controller 
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5.3.3.6 Start-up Integration 

The integrating controller will support the start-up process by setting parameter levels 
for each step of the initialization. These would then be adjusted to account for such 
conditions as failure in existence or being handled by workarounds, power load variations, 
crew size and dispersement variations, materials levels and deployments and others 
which could modify the start up. The controller will then check the parameters against 
the set levels and advise the crew when the next step can be taken. Figure 5.3-9 gives a 
block diagram illustration of the function and the following summarizes the steps. 

1. Receive input that initiates start-up integration. 

2. Determine set of nominal parametric values sequenced to the start-up 
process. 

3. Adjust values to reflect current conditions in the system. 

,4. Trace parameters against adjusted values. 

5. Annunciate instructions on start-up steps to crew. 

5.3 .4 Functional Scenarios 

The following scenarios were developed to describe the operating environment for the 
integrating controller. The first scenario is for initialization of a space station system. 
This scenario is conceptual in nature and as such is subject to modification as the space 
station design develops. The second scenario is for a shift in life support modes on a 
space station. 

5.3.4. 1 System Initialization Scenario 

This scenario is to describe events that might occur as a space station module is initial- 
ized for habitation by the crew. It is assumed that the shuttle is attached and that the 
crew relies on the shuttle systems to support the initial EVA. As can be seen, no 
attempt is made to work out the specific number of orbits for this process. The 
initialization crew will start out using EVA and then will go to shirt sleeves after orbit L. 
The initialization crew would be two or possibly three astronauts and would be joined by 
the remainder of the crew after orbit W. 



Orbit 

1. Close cabins and establish initial atmosphere 

N 

2. Cabin power available 

N + M 

3. Cabin heat exchangers 

N+M+l 

4. Cabin Trace Contamination Control (TCC) on 

N+M+l 

5. Cabin dehumidifiers on 

N+M+l 
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Figure 5.3-9. Functional Block Diagram for Startup Integration 
by an integrating Controller 
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6. O2 generators on L+R = 2 

7. N2 supply opened L+R = Z 

8. Cabin air heaters on L+R = Z 

9. CO2 removal on Z+l 

10. CO2 reduction on Z+2 

11. Crew begins cabin occupancy Z+S = W 

12. Potable water loop on Z+S = W 

13. Hygenic water loop on Z+S = W 

14. Wash water loop on Z+S = W 


Between 1 . and 2., several crew members using EVA will inspect and set up cabin interior 
in a physical sense. This will take M orbits to accomplish and then the power to the 
cabin will be initialized. After an additional orbit for EVA inspection, the cabin heat 
exchangers, TCC, and dehumidifiers will be turned on. This will include astronauts in- 
stalling LIOH sorbant units and charcoal units in the TCC and inspecting the progress of 
the system turn on visually. Sensors in the TCC, as well as temperature and humidity 
sensors will be monitored by their respective control systems and the integrating con- 
troller will be notified when readings meet specifications. The integrating controller 
will then communicate to the initialization crew that the-C^ generators and N2 may be 
turned on. The time required for the TCC, dehumidifiers and heat exchangers to meet 
spec will be compared with the expected time by the controller, and if a discrepancy 
exists it will advise the EVA crew on possible repairs or adjustments. Once O2 and N2 
are flowing to the cabin the air heaters will be turned on and their operation inspected 
by the initialization crew. The integrating controller will be notified when the systems 
meet spec, and it will compare performance with the expected time and notify crew on 
adjustments to the system. The CO2 removal and reduction systems will be turned on as 
soon as the O2, N2 and air heater systems are determined to be performing properly. 
Again, the controller determines if the systems reach specified performance in the pre- 
scribed time and notifies the crew that is conducting the initialization of any adjust- 
ments which are needed. Once the CO2 removal and reduction systems are on line the 
entire crew, may inhabit the cabin. The water loops will then be closed with the inte- 
grating controller monitoring elapsed time against the expected period and providing 
annunciation to the crew if any repairs or adjustments are needed. 

During this entire process, the controller will perform its power, materials transfer, and 
redundant path management functions for those systems that are on line. 


159 



D1 80-27935-2 


5.3. 4.2 Mode Shift Scenario 

This sequence is the result of a change in the life support subsystem operating mode 
between the nominal, degraded, or emergency set points. Again this is a conceptual 
sequence of events to be described more specifically after the space station design 
becomes more defined. 

1. Mode change selected either by crew or the integrating controller. 

2. The integrating controller then adjusts control limits for each automatic 
system reference to correspond with selected mode. 

3. System configured for mode shift as necessary by commands from the inte- 
grating controller. 

a. Materials transfer. 

b. Power adjustments. 

c. Path selection. 

4. Maintenance schedule adjusted as needed. 

5. Annunciation to crew. 

6. Implement mode shift. 

Astronaut adjusts the life support set point from nominal to degraded or emergency 
mode or the mode shift is selected by the integrating controller in response to deficient 
operation due to failure, power deficiency, materials enbalance, or maintenance action. 

Integrating controller then adjusts control system references to each subsystem automa- 
tion unit in a scheduled and locational pattern based on the location and status of the 
deficiency and the status of the subsystem at the time when the deficiency is detected. 

The integrating controller also checks levels of materials in storage, monitors power 
deficiencies and failure modes, and commands appropriate transfers, load reductions, or 
redundant path actions. The integrating controller reschedules routine maintenance to 
occur after the selected degraded or emergency mode is over whenever possible. 

If the action involves the shut down of a space station module, the integrating controller 
will command the flow of materials from the module to be shut down to ones to be occu- 
pied and will verify the egress of all crew members from that module before allowing the 
hatch to be closed. 
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5.3.5 Hardware and Software Elements 

An integrating controller will consist of on-board central and distributed processors that 
will initially be supported by an earth-based central data processing facility which can be 
used by employing the telemetry link. The processing functions will be largely in the on- 
board central processor for all decision making and command generating. The distrib- 
uted processors will be used for data collection and command execution functions. The 
earth bound facility will be used for some off-line comparisons and determinations espe- 
cially for failure diagnostics and logistics control. Figure 5.3-10 shows a typical proc- 
essor hierarchy and data path connection concept for a integrating controller. The dia- 
gram indicates where the functions are in the central processor and where they are 
distributed* 

The following paragraphs summarize the separate processor functions. 

5.3.5. 1 Data Collection Processors 

These would be distributed processors located near the subsystem elements where the 
data is being collected and would perform the following processing functions: 

1. Select data to be sampled. 

2. Select rate of data to be sampled. 

3. Select sequence of samples. 

4. Process sample data for presentation to the central processor. 

5.3.5.2 Comparison Processor 

This would be an entry processing element of a central processor and would perform the 
following functions: 

1. Compare data received with past data. 

2. Compare data received with standard values. 

3. Compare data received with other data received. 

These comparisons will be used by the decision making processor. 

5.3.5.3 Data Storage Processing 

This would be an entry processing function of a central processor. The data coming into 
a central processor will be stored or discarded and the management of that process as 
well as a review of the data in storage for purposes of determining what is to be purged 
will be the function of the data storage processor. 
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Figure 5.3 - 10. Processing Functional Diagram of Integrating Controller for Automated Housekeeping 
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5.3.5A Decision Processor 

This is a principle function of an onboard central processor and includes the following 
processing subfunctions: 


1. If total power supplied data is less than the total demand data, process a power 
reduction decision. 

2. If failure data is received process a redundant path selection decision. 


3. If materials storage level data is out of agreement with predicted levels, process a 
materials transfer decision. 


4. If data indicates a change in maintenance schedule as a result of action taken on 
failure events, a schedule revision is selected. 

5. If data indicates that performance is not being met, a decision on going to 
degraded or emergency mode will be processed. 



6 . 


If localized performance degradation exists as shown by data received a decision is 
processed on closing off a space station module. 


7. If a problem indication is detected process a failure isolation interactive routine 
and the resulting failure identification decision. 

8. If a start-up mode is requested process a start up support and interactive routine 
and process start up step decisions. 


5.3.5.5 Predictor Processing 

The decision processor is supported by several other processor functions. One of these is 
the predictor processor. It performs the following actions: 


1. Predictions will be made as to the consequences of actions being considered by the 
decision processor. 



Predictions will be processed to identify when an action that has been commanded 
must be changed or new decisions must be made. 
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5. 3.5.6 Priority Processing 

Another function that supports the decision maker is the priority processor. As part of 
the decision making process, prioritized lists will be established and revised by the prior- 
ity processor. 

5.3. 5.7 Command Processing 

The actions, sequencing, and quantitative aspects of commands will be processed once 
decisions are made. This function will be accomplished in part by the central processor 
and in part by distributed processors located where the commands are executed. 

The central processor will issue the command in general terms to the distributed proces- 
sors. Each distributed processor will interprete the general command for the particular 
system element that the distributed processor is supporting. 

5.3.5.8 Earth Based Processing 

Failure diagnosis, logistics modifications, problem solutions for communication to the 
crew would be processed initially by an earth-based data processing facility when time 
delays from off-line processing could be tolerated. This facility could also be used for 
simulation and check out of software modifications prior to implementing them in' the 
onboard system. 

5.3.6 Expert Systems Considerations 

This section consists largely of the responses received to the questions poised under sec- 
tion 5.2.4. The following functions of the integrating controller were indicated by those 
responses to be definite candidates for some expert systems processing. 

1. Electrical power load management— the MSFC has a study that is being conducted 
by Martin Marietta and the indications from that study are that expert systems 
apply to this function. 

2. Redundant path selection— work is being done to apply expert systems to this 
problem for nuclear power plants. 

3. Maintenance schedule management— this general area is considered to be a 
promising application of expert systems. 
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All of the other functions were considered by the responses to be good possibilities for 
at least partial application of expert systems. 

In theory, expert systems can't do anything that conventional automation can't and vice 
versa. In practice, there are differences in application that favor one approach over the 
other. Conventional automation seems to be best if the problem is highly deterministic 
or when there is a good theory. Expert systems seem to be best in situations where repeti 

i 

tive, comparatively low-level judgements are made. Judgements, in this case are deci- 
sions for which there are no clear cut guidelines. 

The mode select scenario seems to have a substantial judgemental aspect to it. This is 
illustrated by the following example: 

Assume we have gotten into a situation as shown in the figure 5.3-11. Because there is 
no H2> we cannot reduce the C02* This means we cannot empty the C02> storage con- 
tainer, which in turn means we cannot purge the SAWD canisters in the CO 2 removal 
unit. This means that the CO 2 level in the cabin may increase to an undesirable level. 

There are several responses that may be made to this situation. Some include the fol- 
lowing: 

1. Dump some CO 2 overboard— this is undesirable because it represents the loss of re- 
sources, may contaminate sensors, and violates "no dump" space station ground 
rule. 

2. Generate some O 2 — this will create H 2 so that we can reduce the CO 2 . However, 
this will take time to do, and in the interim, the CO 2 may become degraded. 

3. Transfer crew to another cabin— this will solve the problem unless the CO 2 removal 
unit in the other cabin is operating in a degraded mode, in which case we make 
things worse in the other cabin. 

4. Transfer CO 2 to another cabin— this will also solve the problem unless the other 
cabin has a problem too. 
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None of these responses is completely satisfactory. In addition, there may be some second- 
ary factors. For example, a shuttle resupply flight might be delayed, which means that 
it is extremely desirable to conserve resources. 

It is not obvious that there is a technical answer of what to do in a situation like this. 

The approach is to ask what would a space station commander do given this situation? 
Design the mode selector to do the same thing. This is the expert systems approach. 

On the other hand, not all aspects of the integration control problem require expert sys- 
tems technology. A hybrid controller may be best. With such a controller, there will be 
several expert system components working with conventional parts of an integrating 
controller. This is because expert systems are best if applied so that each handles a 
single specific type of problem. The integrating controller involves solving several prob- 
lems that are quite distinct from the standpoint of an expert system. Techniques can be 
applied to use expert systems that integrate several other expert systems and the conven- 
tional elements using a blackboard concept. Figure 5.3-12 shows how such a concept 
might be structured. 

Using today's technology, expert systems are not good choices for problems that require 
fast solutions (less than minutes). Assuming that life support system operation is syn- 
chronized with the sunny part of the orbit, an expert system decision model would run 
once or twice per orbit (mainly to set the system up for the transition from shadow to 
sun). It would run more often if out-of-the-ordinary situations occurred and that may 
require advancement in current technology. 

Clearly, the onboard integrating controller needs expert systems, but even if it did not, 
there might be advantages to using expert systems technology. For example, the explana- 
tion capability often exhibited by expert systems would be helpful during space stations 
subsystem development. If an integrating controller were built using conventional auto- 
mation, it would be so complex and difficult to understand that it would be desirable to 
train the crew with an expert system that would explain the behavior of the integrating 
controller. 

Any estimate of the size of the expert systems parts of an integrating controller is con- 
strained by the following: 
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1. The preferred current method of developing an expert system is to use an expert 
system language analogous to a programming language for conventional automa- 
tion. The number of statements in a conventional program can vary drastically 
depending on the language. In the case of expert systems, there is probably at 
least a 3:1 variation in number of rules depending upon the language used. 

2. Expert systems do not have to be developed using rules. Rules are a knowledge 
representation technique. There are other ways of representing knowledge includ- 


ing: 


a. 

Logic 

b. 

Networks 

c. 

Frames 

d. 

Hybrid 


This is one reason why an integrating controller would involve several expert systems for 
its different types of functions. 

Given the above caveats, it was estimated that as an example, the inter-subsystem fail- 
ure isolation function expert system would involve from 1,000-3,000 rules, and in that 
case using rules for estimating is probably a good way to go. 

Factors to consider when describing whether to use space-borne or ground-based compu- 
ters for the integrating controller include: 

1. Criticality— will the astronauts be threatened if access to the integrating con- 
troller is interrupted? 

2. Resource usage— does the integrating controller use an excessive amount of space 
borne computer resources? 

3. Data bandwidth— does the integrating contoller process so much data that trans- 
mitting it to earth would jug up the communications channels? 

Because of the criticality of the failure isolation function and redundant path selection 
function, they would be high priorities for space borne implementation. Maintenance 
scheduling could probably be ground based at least in the early stages of the space 
station. 
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In order to estimate the space borne computational capability required, several assump- 
tions will be made: 

1. The expert systems used will be programmed for the onboard system using the LISP 
programming language. (LISP is a heavy user of resources). 

2. The space station has a distributed processing system consisting of general purpose 
as well as special purpose processors. 

3. General purpose processors are machines with 32 bit CPUs, 2 MIPS throughput and 
I megabyte of memory. 

k. Mass storage will be available to store expert systems rules when not actively 
being processed. 

Based on these assumptions, it is estimated that an expert system implementation would 
require a general purpose processor for active processing of each expert system function 
of the type exemplified by inter-subsystem failure isolation system. 

Any large expert system might require a special purpose processor, and unless the func- 
tion was extremely critical for crew safety, it would not be space borne. 

To estimate the effort needed to develop an expert system a single function such as the 
failure isolation is guessed to require at least 5-10 man-years of effort. Assuming one 
expert system per function, 30-60 man-years of effort would be required. (Currently 5 
man-years seems to be the quickest any expert system can be developed). 

All of this indicates that expert systems have a role to play in 
concept, but that they are, when based on current technology, 
ational resources and also of development .effort. 


the integrating controller 
heavy users of comput- 
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5-3.7 Trade Study Comparisons 

The results of the concept characterization studies for an integrating controller are 
basically the definitions of functions to be performed by such a controller and concepts 
for processing of those functions on board the space station or on the ground using distri- 
buted as well as centralized architecture. This paragraph discusses the comparisons 
conducted with respect to these characterizations. 

Figure 5.3-13 gives a trade of the functions of the integrating controller against five 
fairly nonquantifiable criteria. These are: 

1. Frequency of use-this means the relative number of usage instances for the func- 
tion over the operation period of a space station (one time, often, continuous). 

2. Autonomous processing-this is an assessment of how much the astronauts will want 
the function to be autonomous. 

3. Essential for safety-functions are assessed with respect to how essential they are 
to maintaining a space station that is safe for the astronauts, the visiting shuttle 
and the space station missions. 

4. Deterministic processing-this is an assessment of how much of the function is 
based on data and how much is based on know-how of people. 

5. Durability-this is an assessment of wheather the use for the function will increase 
or decrease as the space station matures. 

The cumulative rankings of the six functions against the criteria used gives the following 
results: 


Electrical power load management 

= 7 

Materials transfer management 

= 9 

Intersubsystem failure isolation 

= 10 

Intersubsystem redundant path select 

= 11 

Start-up integration 

= 17 

Maintenance schedule management 

= 20 


V 
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Figure 5.3- 13 Trade of Integrating Controller Functions 
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This indicates that the start-up integration and maintenance schedule management are 
of lower priority than the other four functions. This seems somewhat reasonable since 
the space station would need the first four for smooth and safe operation while the last 
two would be more like convenience functions. 


The trades between distributed versus centralized architecture are based on mass, vul- 
nerability, maintainability, and cost. 


1. Mass-greater on-orbit mass with distributed, but modern computer technology may 
make the difference trivial. 


2. Vulnerability-greater vulnerability to failures with centralized because functions 
are not repeated. This means that one location failures could result such as thermal 
contact failure, grounding failures, meteroid hits, etc. Even with voting the central- 
ized system would be more vulnerable to failures. 


3. 



Maintainability— distributed system is more easily maintained because repeated 
processing allows natural on-line/off-line configurations. Also standardized 
components are more easily replaced. 


4. Cost— this trade is not clear. There is more hardware with a distributed system but 

it is standardized and therefore not as expensive. There is more network operating 
system software with a distributed system but interfaces are defined by the 
standardized hardware. 


In general a distributed architecture is favored where the requirem ents for computing 
capacity indicated by the function do not dictate extremely large units that would not be 
practical to duplicate on board the space station. 


The trades between onboard versus ground processing are based on the cost of ground 
facilities to communicate with the space station as opposed to the cost of placing the 
facilities on the station with the mass and logisitics penalties as well as the the quali- 
fication costs. Also, onboard mission control would be less labor intensive and therefore 
those costs would tend to be less although the labor rates would be higher in space. 
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The comparison of a fully automatic system versus one where the astronauts interact 
thru a computer terminal involves human preferences. In many cases the astronauts 
would probably prefer not to be bothered with routine diagnosis and corrective action but 
in others such as scheduling and logistics the astronauts would probably want to maintain 
control. In a few cases such as attitude control or some power control the diagnosis and 
corrective action could require faster response than that which is consistent with human 
capability and that would favor the fully automatic approach. Finally the acquisition of 
a knowledge base to develope the integrating controller system will benefit by the inter- 
active experience of astronauts during the early missions. All of this indicates that the 
early space station will be characterized by a great emphasis on interactive controllers 
but as the station matures many functions will want to become fully automatic. 

5.3.8 Cost and Benefits Analysis 

Based on the integrating controller characterization developed in this study and the trade 
study considerations identified above an update of the cost and benefits for advancing 
the expert systems technology can be established. In section 4.1.8 of volume II of the 
Advanced Platform Systems Technology Study Final Report a cost and benefits estimate 
was made for the expert systems technology for an integrating controller. In the current 
study we have developed a more detailed description of the functions of the controller 
and have focused on the programatic trades with respect to those functions and that 
allows a more realistic estimate of costs and benefits. 

The following assumptions are established for the cost update of this current study. 

1. Six expert system functional elements plus one expert system selection element 
will be considered. 

2. Each element is equivilent to one Rl expert system program (850 rules) except the 
intersubsystem failure isolation element, which is assumed to be 2,000 rules per 
section 5.3.6. This gives a total of 7,100 rules for the integrating controller expert 
systems. 

3. Based on the productivity of section 5.3.6 each rule requires 2 days of labor to 
develop. This is better than the productivity rate of 5 labor days per rule used in 
the previous study. We will assume the more conservative 5 days per rule rate. 
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4. Assume a labor rate of $400.00 per man-day for expert systems software develop- 
ment (this is nearly double the rate assumed for the last study). 

5. Assume $1M for verification of each element for a total of $7M. 

6. Based on the estimate of one general processor for each on-line function plus one 
for the expert system selector, we can estimate that at least three onboard general 
processors would be needed to implement the system. Assuming $1M for each we 
have $3M for additional hardware. 

Assembling the results of all the assumptions above gives a cost figure for the expert 
systems development and implementation of $24.2M. 

For the benefits estimate we will consider a phased introduction of the integrating con- 
troller expert systems. This means that the yearly savings assumed in the previous study 
would be reduced. 

The following assumptions apply to the benefits estimates for this study. 

1. The labor to monitor the space station systems would be phased out as the inte- 
grating controller is phased in as follows. 

a. For year 1: Six ground-based mission controllers plus Yi time astronaut (full 
coverage) 

b. For Year 2 thru year 5: One ground-based mission controller plus Yi time 
astronaut. (Reduction of five ground-base mission controllers for 4 years.) 

c. For year 6 thru year 10s 1/10 time ground-based mission controller plus 1/10 
time astronaut. (Reduction of 5.9 mission controllers and 0.4 astronaut foF~5 
years.) 

2. Mission controller labor rate is $1500 per 24-hour day or $550,000 per year for each 
controller. 

3. Astronaut labor rate is $77,000 per 24-hour day or $28,200,000 per year. 

4. Resupply and maintenance cost savings due to the integrating controller are esti- 
mated as $25M over a 10-year mission due to more efficent use of resources onboard 
and more managed maintenance operations. 
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5. 


Half of the above benefits of an integrating controller can be attributed to use of 
expert systems. 


Based on the above assumption the benefits of the expert systems part of an integrating 
controller are estimated at $54M. 


The resulting cost to benefits ratio then is 0.44. This is a significant movement from the 
0.098 ratio estimate of the previous report but still leaves the expert system develop- 
ment with all the associated unquantified benefits as an attractive tecnhology for 
advancement. 


5.3.9 Identification of Technologies for Advancement 

The technology indicated for advancement is to support the development of an integrat- 
ing controller for a space station using expert systems for the mechanization of control- 
ler functions. 


The following tasks are identified to describe the needed advancement in order to pro- 
vide for an integrating controller on the space station. 


1. Define expert system decisions. 

Review the functions of the integrating controller and identify where non deter- 
ministic deicisions have to be made. These would be decisions that either depend 
on more data than is available or on processes that have not been previously 
codified. In some cases expert systems decisions will be those in which no clear 
process is available and the best, to our expert, process will be used. 


2 . 



Acquire initial knowledge base. 

Identify and set up interview sessions with a set of experts to provide knowledge 
for, each of the decisions identified. These interview sessions would be conducted 
by knowledge engineers or specialists who would be trained in the use of natural 
language programming and who can interact with the expert to extract the 
knowledge. The initial experts will be chosen from candidates who are: 

a. Skylab or Shuttle Astronauts 

b. Mission Control Center Specialists 

c. System designers 

d. Technical specialists 
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For each decision process, one expert will be selected and used to develop the ini- 
tial knowledge base. 

As a part of developing the knowledge base the knowledge engineers will code 
expert systems rules and interact with the expert on the result. 

3. Program the integrating controller functions. 

Using the expert systems decisions with the initial knowledge bases and the deter- 
ministic functions, each integrating controller function will be programmed. 
System modules will be identified that can be stored off line and called up by an 
expert system selector elements to implement the overall integrating controller. 
Initially, the system will be an interactive or advisory type. This means that the 
astronauts will be performing functions as data gathers or implementers of action 
according to interactive advise given by the system. 

4. Exercise the integrating controller with future space station operation astronauts. 
Using the integrating controller programmed into an interactive system conduct 
exercises with future operations astronauts for the space station using a set of 
situations typical of expected space station anomalies. Using the results of this 
exercise return to the experts with any needs for updating or adjusting the expert 
systems, or the other parts of the integrating controller. 

The following tasks are identified to implement the initial integrating controller. 

1. Establish the baseline integrating controller for the initial space station. 

Using the updated integrating controller program establish flight software that is 
tailored to onboard flight hardware and to an operational architecture to be used 
on the space station. 

2. Verify the integrating controller flight baseline. 

By using the system in a space station mockup with operations astronauts and a set 
of expected situations, check out the baseline integrating controller. 

The following tasks are identified to describe the needed updating of the initial system 
to reach the desired configuration. 
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1. Update the baseline system. 

During the first several years of flight, the operations personnel for each crew 
would be interviewed by knowledge engineers as they return from their 90-day 
tours. These interviews will be used to update the knowledge base for the expert 
systems used on the space station. 

2. Automated integrating controller functions. 

Based on astronaut experience functions to be automated (rather than being inter- 
active) will be identified. This will be largely in response to astronauts prefer- 
ences; some things they will want to hang onto others they will want to be rid of. 
For those where sensors or actuators are feasible integrating controller functions 

v. 

will be reprogrammed to rid the astronauts of unwanted interactions. An ongoing 
program to identify where sensors /actuators are likely to be wanted and to initiate 
necessary developments should be defined early in the effort. 

5.4 SUMMARY OF RESULTS 

This section summarizes the results of the tasks conducted on the Integration of Auto- 
mated Housekeeping for an inhabited space station as part of this study. 

5.4.1 Task 1 Results 

The first major result is the identification of automation functions and quantities to be 
sensed to perform those functions. Tables 5.3-1, 5.3-2, and 5.3-3 list these for the elec- 
trical power subsystem, the life support subsystem and the thermal control subsystem 
respectively. These functions and sensor indicators were used to identify the major 
result of task 1. This result is the description of six functions to be performed by an 
integrating controller. These six functions are described and diagrammed under section 
5.3.3 and are listed here as follows: 

1. Electrical power load management. 

2. Materials transfer management. 

3. Intersubsystem failure isolation. 

4. Intersubsystem redundant path selection. 

5. Maintenance schedule management. 

6. Start-up integration. 
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Another result is that the processing for the integrating controller will be partly func- 
tionally distributed and partly functionally centralized on board the space station. The 
exact organization of hardware remains undetermined at this time because the configura- 
tion of the space station as well as groundrules for the architecture of the data process- 
ing system are undefined. Figures 5.3-10 and 5.3-12 give indicators of how the system 
architecture and integrating controller hierarchy might be managed in a functional sense. 

The final task 1 result was a review of expert system applicability to the integrating 
controller that indicates the following: 

1. The integrating controller functions would profit from use of expert systems. 

2. That the expert systems would require a large onboard data processing capability. 

3. That selection of on-line expert systems elements from a mass memory storage 
device by an expert systems selector would be necessary. 

4. That expert systems development costs would be significant because this integra- 
ting controller application exceeds anything that has been done to date in expert 
systems technology both in size and in the breadth of the functions covered. 

5.4.2 Task 2 Results 

The comparison of integrating controller functions indicated that the maintenance sche- 
duling and start-up integration function were of lower priority than the other four. 

Ground-based control and interactive onboard control have advantages in an early space 
station program with more autonomy both to the space station and to the automatic 
systems on board as the space station matures. 

The cost of developing expert system elements for an integrating controller was reas- 
sessed based on the characterization developed in this study. The result was an increase 
in the estimated cost from $9.0M to $24.2M. Part of this was a more realistic labor rate 
figure for knowledge engineers and LISP programmers and part was the inclusion of imple- 
mentation and post-launch updating costs. 
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The benefits from the expert system elements were also reassessed based on the phased 
implementation of the integrating controller now seen as a more likely possibility. This 
produced a $54. 3M benefit as opposed to the $92M benefit estimated in the last study for 
the first ten years of the space station program. 

The resulting 0.44 cost benefit figure for expert systems advancement is not as enticing 
as the 0.098 figure produced in the last study, but the greater figure from this study still 
indicates a worth while technology for advancement. 

5.5 CONCLUSIONS 

The conclusion from this study are: 

1. The integrating controller has real and useful functions on a space station. 

2. The implementation of the controller would profit from expert systems programming. 

3. The implementation will be phased and updated during the early years of the space 
station operations. 

4. The costs are high but so are the benefits. 

5. This technology advancement is essential if the space station autonomy /automation 
philosophy listed on table 5.1-1 is to be implemented. 

5.6 RECOMMENDATIONS 

The recommendation from this study is to proceed with the technology development for 
expert systems elements and the implementation of an integrating controller as outlined 
in section 5.3.9. 

Volume HI of this report includes a section that defines a plan for development of this 
technology and implementation on a space station during the 1990's. 
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